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Vorwort 


Nachdem die Amiga-Euphorie allmählich abgeklungen war und 
man festgestellt hatte, daß der Amiga nicht nur eine tolle Gra¬ 
fik- und Sound-Maschine, sondern auch für die sogenannten 
"ernsthaften" Anwendungen zu gebrauchen ist, wurden die Rufe 
nach Literatur zum Programmieren dieser ernsthaften Anwen¬ 
dungen immer lauter. In diesem Buch wollen wir Ihnen daher 
näherbringen, wie Sie viele der Betriebssystemfunktionen des 
Amiga sinnvoll für Ihre eigenen Programme anwenden können. 

Da dies alles auf der Ebene der Programmiersprache C abläuft, 
wird vor dem eigentlichen "Programmierlehrteil" die Funktions¬ 
weise eines C-Compilers erläutert. Diesen Part übernimmt Bruno 
Jennrich, der seine langjährige Programmier-Erfahrung hier 
einbringt. In diesem Teil werden Sie mit den Ursachen bekannt 
gemacht, die z.B. die "Casts" notwendig machen usw. So können 
Sie vor allen Dingen bei großen Projekten Zeit und Nerven 
sparen. Wenn Ihnen bisher einige Besonderheiten der Sprache C 
Schwierigkeiten gemacht haben und dies zu Fehlern und Pro¬ 
grammabstürzen führte - nach diesem Buch machen Sie 
höchstens noch Flüchtigkeitsfehler. 

Danach erhalten Sie eine Einführung in das bisher recht stief¬ 
mütterlich behandelte Thema "Intuition". Wolf-Gideon Bleek, ein 
Spezialist auf diesem Gebiet, wird Sie in die Tiefen der Benut¬ 
zeroberfläche Intuition hinabführen. Danach werden Sie keine 
Probleme mehr haben, Ihre eigenen Programme mit Windows, 
Screens, Menüs, Gadgets und anderen Bestandteilen von Intui¬ 
tion übersichtlich und komfortabel zu gestalten. 

Im dritten Teil, für den Peter Schulz, bekannt durch seinen 
"Profimat" und das Buch "3-D-Grafikprogrammierung", verant¬ 
wortlich zeichnet, werden schließlich die Intuition-Kenntnisse 
eingebettet in ein Projekt - Stück für Stück entwickeln Sie mit 
Peter Schulz einen Editor. Dabei bleiben heikle Themen wie z.B. 
die Tastaturabfrage, der Diskettenzugriff usw. keineswegs unan- 



getastet. Sie lernen also den Umgang mit den Devices und an¬ 
deren, auch stiefmütterlich behandelten Librarys kennen. 

Insgesamt ist dieses Buch also ein Werk, das der ernsthafte Pro¬ 
grammierer immer griffbereit neben seinem Amiga liegen haben 
sollte. 


Die Autoren 


Februar 1988 
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1. Die Sprache C 

Im Jahre 1972 setzte sich Dennis Ritchie daran, die aus der 
Sprache BCPL (Basic Combined Programming Language) ent¬ 
standene Sprache B zu überarbeiten. Diese Überarbeitung wurde 
die Sprache C. 

Sie wurde entwickelt, um das Unix-Betriebssystem leichter auf 
PDP-Rechnern (der Firma DEC), insbesondere auf der PDP-7, 
implementieren zu können. Damals hätte sich Dennis Ritchie 
sicherlich nicht träumen lassen, daß seine Sprache heute einen 
solchen Boom - vor allem auf dem Homecomputer-Sektor - er¬ 
lebt. 

Dies liegt wohl daran, daß C eine äußerst effiziente Hochsprache 
ist. Diese Effizienz kommt den Homecomputern sehr entgegen, 
die ja meistens an Speichermangel leiden, und unter Zeitdruck 
stehen, bzw. niedrige Taktfrequenzen und langsame Programm¬ 
ausführungszeiten haben. 

Der Code, den der C-Compiler erzeugt, ist sehr kompakt und 
schnell auszuführen, was denjenigen Programmierern, die lieber 
auf Maschinensprache verzichten und dennoch schnelle Pro¬ 
gramme schreiben müssen oder wollen, sehr entgegen kommt. 

Leider hat sich die Idee der Super-Portabilität nicht realisieren 
lassen. Ursprünglich sollte jedes C-Programm auf jedem C- 
Compiler laufen. Aber unterschiedliche Betriebssysteme machten 
unterschiedliche Compiler nötig, und so wurde die Kompatibili¬ 
tät nahezu unmöglich. 

Ein kleines Beispiel zeigt die Schwierigkeiten auf, die sich für 
die "Super-Portabilität" ergeben; 

Schon zwischen Amiga und Atari ST treten so starke Differen¬ 
zen auf - obwohl beides 680000er Rechner sind - , daß ein ST- 
Programm, das auf Betriebssystemroutinen des GEM, VDI oder 
AES zurückgreift, nur auf dem Amiga zum Laufen gebracht 
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werden kann, wenn man die Betriebssysteme beider Rechner ge¬ 
nau kennt und weiß, welcher Betriebssystemaufruf des ST durch 
welchen Betriebssystemaufruf des Amiga ersetzt werden muß. 
Das ganze verkompliziert sich natürlich dann, wenn ein Pro¬ 
gramm vom IBM PC auf den Amiga übertragen werden soll. Die 
Tatsache nämlich, daß beim IBM PC die sogenannte Segment- 
Adressierung benutzt wird, macht dort umständliche FAR-De- 
klarationen (engl.: far = deutsch: weit) von Variablen und Funk¬ 
tionen notwendig. Und auch die Tatsache, daß MS-DOS-Funk- 
tionen fast ausschließlich über Interrupts aufgerufen werden, 
macht bei der Übertragung von IBM-Programmen die genaue 
Kenntnis der Betriebssysteme zur Voraussetzung. Man muß wis¬ 
sen, welche Funktion des MS-DOS welche Funktion des Amiga- 
DOS übernehmen könnte. 


1.1 Überbleibsel der Geschichte 

Sicher wissen Sie, daß verschiedene Teile des Amiga-Betriebssy- 
stems in C entwickelt wurden. Sie werden sich sicher fragen, 
wie das möglich war - schließlich ist ein Betriebssystem doch 
das, was den Computer mit Leben erfüllt. Da aber auch ein C- 
Compiler ohne Betriebssystem nicht funktioniert, kann das doch 
eigentlich nicht ganz richtig sein! 

Es stimmt aber doch! Und zwar wurde das Amiga-Betriebssy- 
stem auf SUN-Workstations entwickelt. Über die serielle 
Schnittstelle hatte man von der SUN aus Kontrolle über den 
Amiga. Dies ist übrigens der Grund, warum beim Aufruf des 
ROMWACK (des Amiga-Debuggers) nach der seriellen Schnitt¬ 
stelle gefragt wird. Beim Auftreten eines Fehlers hatte man dann 
nämlich die Möglichkeit, diesen von der SUN aus zu finden und 
zu beheben. 

Die Tatsache, daß das Amiga-Betriebssystem auf einer SUN 
entwickelt wurde, hat aber einen Nachteil: Da nämlich der 
Amiga zunächst von der Firma Amiga entwickelt, und die Ent¬ 
wicklung dieses Rechners von Commodore erst begonnen wurde, 
als Amigas finanzielle Grundlage zu schwinden begann, ist 
hierin wahrscheinlich der Grund zu sehen, daß auch die Sprache 
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BCPL bei der Betriebssystementwicklung Verwendung fand. 
Diese Tatsache macht sich manchmal unangenehm bemerkbar, da 
in der Sprache BCPL Zeiger etwas umständlich verwaltet wer¬ 
den. 

BCPL-Zeiger dürfen nämlich nur auf durch 4 teilbaren Adres¬ 
sen zeigen. Bei der Verwendung eines BCPL-Pointers muß des¬ 
sen Wert also zunächst mit vier multipliziert werden, um die 
tatsächliche Adresse zu erhalten. Wenn Sie eine Adresse einem 
solchen BCPL-Zeiger zuweisen wollen, müssen Sie diese 
zunächst durch 4 teilen. 

Auch Strings haben ein etwas abweichendes Format. Erstens 
werden nur die oben beschriebenen BCPL-Zeiger verwendet. 
Das erste Byte, auf das dieser Zeiger zeigt, enthält dabei aller¬ 
dings nicht wie zu erwarten das erste Zeichen des Strings, son¬ 
dern die Anzahl der Zeichen des Strings. Erst dann folgen die 
einzelnen Zeichen. 

Jedoch sollen uns die Probleme im Zusammenhang mit den 
BCPL-Zeigern und -Strings nicht weiter interessieren, da diese 
Zeiger recht selten auftreten - eben nur bei der Programmierung 
des AmigaDOS (dos.library). Wir wollten nur demonstrieren, daß 
die Entwicklung des Amiga scheinbar recht umständlich von¬ 
statten ging. 


1.2 Der Aztec-Compiler 

Doch wenden wir uns von den Kompatibilitätsproblemen ab und 
ausschließlich dem Amiga zu. Hier stehen wir nämlich vor der 
Glaubensfrage, welchen Compiler wir verwenden wollen. Die 
eingefleischten Lattice-Programmierer schwören auf die Zuver¬ 
lässigkeit des Lattice-Compilers - es wurden ja auch einige Teile 
des Amiga-Betriebssystems auf dem Lattice-Compiler verfaßt -, 
während Aztec-Programmierer auf die Geschwindigkeit ihres 
Compilers setzen. 
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Wir werden Ihnen in diesem Buch beide Compiler vorstellen und 
erklären, wie Sie diese zu benutzen haben, um optimale C-Pro- 
gramme zu erstellen. 

Wir verwenden in diesem Buch jedoch den Aztec-Compiler 
(V3.6). Um den Aztec-Compiler einsetzen zu können, muß na¬ 
türlich bekannt sein, wie man den Comiliervorgang beeinflussen 
kann. Dies geschieht mit Hilfe von Compiler-Optionen. 


1.2.1 Die Installation 

Kommen wir also zum Compiler-Paket der Firma Manx. Es ent¬ 
hält vier Disketten. Neben dem Compiler, Assembler und Linker 
befinden sich auf diesen Disketten auch sämtliche Include-Files 
und die verschiedenen Bibliotheken, die zum compilierten und 
assemblierten Programm hinzugelinkt werden können (siehe auch 
Kapitel 2.3). Zusätzlich befinden sich einige nützliche Pro¬ 
gramme auf den Disketten, die Ihnen z.B. erlauben, eigene Rou¬ 
tinen in die zuzulinkenden Librarys aufzunehmen etc. 

Doch beschäftigen wir uns damit, was für den Betrieb des Com¬ 
pilers unbedingt wichtig ist: Auf der Diskette SYSl des Pakets 
finden Sie neben einer vollständigen, nutzbaren Workbench-Dis- 
kette drei weitere Unterverzeichnisse: bin/, include/ und lib/. 

Im Verzeichnis SYSLbin/ befinden sich alle nötigen Programme 
für den Betrieb des Compilers: also der Compiler selbst (File cc), 
der einen Assembler-Source erzeugt, der Assembler (as), der 
diesen Source assembliert, und der Linker (ln), der den Objekt¬ 
code des Assembler-Source mit den Librarys, die im Unterver¬ 
zeichnis SYSLlib enthalten sind, verbindet, um ein lauffähiges 
Programm zu erzeugen. 

Im Unterverzeichnis SYSLinclude sind die einzelnen Header¬ 
oder Include-Files enthalten, die in jedes C-Programm einge¬ 
bunden (included) werden müssen, das auf Betriebssystemstruk¬ 
turen zugreift. (Die Include-Files werden manchmal auch Bin- 
dings genannt.) Leider kann es bei der Verwendung der V3.6- 
Includes zu Problemen kommen, denn um das Compilieren der 
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Include-Files zu beschleunigen, hat man aus allen Include-Files 
der Version 3.6 alle Kommentare entfernt. Bei verschiedenen 
Include-Files hat man auch das Präprozessor-Kommando #endif 
am Ende einiger Include-Files entfernt. Dies führt beim Compi- 
lieren zu Fehlern. Sollte einmal ein diesbezüglicher Fehler auf- 
tauchen, müssen Sie das Include-File suchen, in dem das #endif 
fehlt, und dieses Kommando am Ende des Include-Files einfü- 
gen. (Das Kommando #endif fehlt z.B. im Include-File intui- 
tion/intuition.h.) 

Auf der zweiten Diskette des Paketes - SYS2: - finden Sie neben 
Assembler-Include-Files weitere Librarys, die Sie je nach Bedarf 
zu Ihren Programmen linken können (siehe auch Kapitel 2.3). 

Mit diesen beiden Disketten kann das C-Programmieren auch 
schon losgehen. 

Jedoch kann man mit den Hilfsprogrammen der dritten Diskette 
- SYS3: - das Compilieren wesentlich einfacher gestalten (siehe 
auch Make). 

Diskette - SYS4: - enthält schließlich im Unterverzeichnis arc/ 
sämtliche Assembler- und C-Aufrufe der einzelnen Betriebssy¬ 
stemroutinen. Diese Assembler- und C-Files wurden assembliert 
und compiliert, zur c.lib, m.lib und s.lib zusammengefaßt und 
können in dieser Form zu Ihren Programmen gelinkt werden. 

Doch kommen wir zum Compilieren von Programmen; 

Schon Diskette 1 reicht aus, um kleine Programme zu compilie¬ 
ren. Dazu müssen Sie aber erst einmal eine Startup-Sequenz an- 
legen: 


setmap d ;Deutschen Zeichensatz laden 

stack 10240 ;Stack sollte irifner 10 KByte oder mehr 

;bet ragen 

copy dfO:lib/c.lib to ram: 

;Häutigst zu linkende Library in RAM- 
;Disk kopieren 
bin/set INCLUDE=dfO:include 

;Wo sind die Include-Files? 
bin/set CLIB=ram:!df0:lib 

;Wo findet man die Librarys? 
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bin/set CCTEMP=ram: 

;Wohin mit den temporären Files? 
bin/setdat ;Datum und Uhrzeit einstellen 

»•(Wichtig für Make!) 

run bin/mclk ;Uhr mit Speicheranzeige starten 

Diese Startup-Sequenz sorgt zunächst einmal dafür, daß der 
deutsche Tastaturtreiber geladen und der Stack auf 10240 Bytes 
erhöht wird. Dies ist eine Präventivmaßnahme, die Sie bei der 
Entwicklung von Programmen vor einem Stack Overflow schüt¬ 
zen soll. (Eine weitere Maßnahme gegen den Stack-Überlauf 
lernen Sie später noch kennen.) Dann wird die Linker-Library, 
die zu jedem C-Programm gelinkt werden muß, in die RAM- 
Disk kopiert, um den Zugriff auf diese Funktionsbibliothek zu 
beschleunigen. Diese Bibliothek ist nicht das gleiche wie z.B. die 
Graphics.Library, welche die Adressen der einzelnen Grafik¬ 
funktionen des Betriebssystems enthält. 

Die Librarys, die vom Linker zum C-Programm gelinkt werden, 
bestehen nur aus kleinen Maschinensprache-Segmenten, die un¬ 
ter Verwendung der von Ihnen eröffneten System-Librarys die 
eigentlichen Betriebssystem-Routinen aufrufen. 

Doch zurück zur Startup-Sequenz. Nun werden nämlich die Um¬ 
gebungsvariablen des Compilers gesetzt, bin/set lNCLUDE=dfO: 
include sorgt dafür, daß bei der Angabe von z.B. #include 
exec/types.h, das Unterverzeichnis dfOrinclude nach dem ange¬ 
gebenen Include-File durchsucht wird. Wurde das File 
exec/types.h im Directory dfO:include gefunden, so wird dieses 
eingebunden (included). Ähnlich verhält es sich mit der Umge¬ 
bungsvariablen CLIB. Diese Variable bestimmt, welches Unter¬ 
verzeichnis nach den zuzulinkenden Bibliotheken durchsucht 
werden soll. Durch bin/set CLIB = ram:!dfO:lib wird beim Lin¬ 
ken von Bibliotheken zuerst die RAM-Disk nach der zu linken¬ 
den Library durchsucht. Wenn das File dort nicht gefunden 
werden konnte, wird das Verzeichnis df0:lib durchsucht. (Sollen 
mehrere Verzeichnisse durchsucht werden, so werden die einzel¬ 
nen Directorys durch ! abgetrennt.) 

Die Umgebungsvariable CCTEMP gibt an, wo die temporären 
Assembler-Files abgespeichert werden sollen. Der Compiler er- 
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zeugt temporäre Assembler-Source-Files im angegeben Unter¬ 
verzeichnis, die dann später zu einem kompletten Source-File 
zusammengefaßt und vom - automatisch aufgerufenen - As¬ 
sembler assembliert werden. 

Als nächstes wird in der Startup-Sequenz das Datum und die 
aktuelle Uhrzeit erfragt. Diejenigen unter Ihnen, die eine Akku¬ 
gepufferte Uhr besitzen, sollten die Uhzeit und das Datum in 
der Startup-Sequenz so einstellen, wie es in der Anleitung zu 
ihrer Uhr steht. Alle anderen sollten aber die Uhrzeit und das 
Datum korrekt eingeben, zumal dies eigentlich nur beim An¬ 
schalten des Rechners bzw. ersten Start des Compilers notwendig 
ist. Nach einem Reset brauchen Sie bei der Erfragung der Uhr¬ 
zeit und des Datums jeweils nur <Return> einzugeben, da Datum 
und Uhrzeit Datum nach einem Reset nicht gelöscht werden. 
(Die Uhr läuft zwar nicht weiter, aber das macht sich meist nur 
in wenigen Sekunden Zeitverlust bemerkbar.) 

Zum guten Schluß der Startup-Sequenz wird das Programm melk 
gestartet, welches dafür sorgt, daß in einem kleinen Fenster, das 
in der Kopfzeile des CLI-Windows plaziert wird, die aktuelle 
Uhrzeit und das noch freie Chip- und Fast-Memory angezeigt 
werden. Dies ist allerdings nicht unbedingt notwendig, doch 
kann es bei der Entwicklung von Programmen interessant sein, 
ob das Programm den belegten Speicher auch wieder restlos frei¬ 
gibt. (Dieses Programm ist also recht nützlich bei der Programm¬ 
entwicklung, weil Sie hier die Möglichkeit haben zu erkennen, 
ob Ihr selbstverfaßtes Programm den belegten Speicher auch 
wieder freigibt. Wenn nicht, müssen Sie wohl noch einen Fehler 
im Programm haben.) 

Nach dieser Initialisierung ist es möglich, kleine Programme mit 
nur einem Diskettenlaufwerk zu compilieren. Für größere Pro¬ 
gramme wird man aber nicht umhinkommen, mit zwei Laufwer¬ 
ken (bzw. Disketten) zu arbeiten. Dann kann man z.B. die C- 
Sources auf die zweite Diskette schreiben. 
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1.2.2 Das Compilieren 

Jetzt stellt sich allerdings die Frage, wie man ein Programm 
compiliert. Eine Möglichkeit besteht darin, sich ein Batch-File 
zu erstellen, das durch execute ausgeführt wird. 

Ein Batch-File der einfachsten Bauart sieht so aus: 

.key file 

SYS1:bin/cc <fUe> 

SYS1:bin/ln <file>.o -IRAMic 

Das Programm file.c wird erst einmal durch den Compiler "ge¬ 
jagt", der automatisch den Assembler aufruft, der den vom 
Compiler erzeugten Assembler-Source assembliert. Das vom As¬ 
sembler erzeugte Objekt-File wird dann mit der c.lib zu einem 
lauffähigen Programm zusammengelinkt. 

Vorausgesetzt der Name des Batch-Files ist comp, wird ein C- 
Programm durch execute comp c-prog compiliert. Den Compi- 
lier-Vorgang können Sie dann durch Ctrl-C beim Compilieren 
und Linken unterbrechen. (Rufen Sie den Assembler selber auf, 
können Sie auch beim Assemblieren die Abarbeitung des Batch- 
Files unterbrechen.) Dies liegt daran, daß der FAILAT-Level 
ohne eine Änderung Ihrerseits nach dem Laden der Workbench 
auf 10 steht. Der Compiler und Linker brechen den Compilier- 
bzw. Link-Vorgang nach Ctrl-C mit exit(lO) ab. Dadurch wird 
auch die Ausführung des Batch-Files unterbrochen. 

Eine weitere Möglichkeit, die Abarbeitung des Batch-Files zu 
unterbrechen, ist Ctrl-D. Das Batch-File wird allerdings erst 
dann unterbrochen, wenn das aktuelle CLI-Kommando komplett 
abgearbeitet wurde. Wurde der Compiler gestartet und danach 
Ctrl-D gedrückt, muß man so lange warten, bis der Compiler 
mit seiner Arbeit fertig ist. 


1.2.3 Die Verwendung von Make 

Batch-Files sind für größere Projekte, die meist aus mehreren 
Modulen bestehen, äußerst unpraktisch. Schreiben Sie sich z.B. 
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ein Batch-File, das alle Module compiliert und zusammenlinkt, 
so müssen Sie, obwohl Sie vielleicht nur eine Kleinigkeit in ei¬ 
nem einzigen Modul geändert haben, solange warten, bis alle 
Module compiliert und zusammengelinkt sind. 

Sie können natürlich auch das geänderte Modul von Hand, also 
durch einen direkten Compiler-Aufruf compilieren und ebenso 
"von Hand" mit den anderen Modulen zusammenlinken. Dies ist 
aber auf die Dauer sehr mühsam. Außerdem müßten Sie den 
Compiler mit SYSl:bin/cc CPRG aufrufen. Dies ist auch auf die 
Dauer sehr umständlich. (Wenn Sie allerdings mit PATH 
SYSlrbin dafür sorgen, daß neben dem aktuellen und dem Ver¬ 
zeichnis SYSl:c auch das Verzeichnis SYSl:bin nach CLI-Kom- 
mandos durchsucht wird, reicht der einfache Aufruf cc CPRG, 
um den Compiler zu starten. Wie Sie vielleicht bemerkt haben, 
muß das Anhängsel .c bei der Übergabe des zu compilierenden 
Programms an den Compiler nicht unbedingt mit angegebenen 
werden. Stellt der Compiler fest, daß dieses Anhängsel (Tag) 
fehlt, hängt er es automatisch an den angegebenen File-Namen 
an. Auch dem Linker muß nicht unbedingt das Tag .0 für die zu 
linkenden Objekt-Files übergeben werden.) 

Um den Compilier-Vorgang zu erleichtern enthält der Aztec- 
Compiler neben Beispielprogrammen und weiteren Librarys un¬ 
ter den Hilfsprogrammen auf der Diskette SYS3: im Verzeichnis 
bin das Tool Make. (Hier befindet sich übrigens auch der De¬ 
bugger DB.) 

Mit Make ist es möglich, große Programme, die der Übersicht¬ 
lichkeit halber immer aus mehreren Modulen bestehen sollten, 
sehr einfach zu compilieren. Man muß sich nicht selbst daran¬ 
setzen, das gerade geänderte Programmmodul zu compilieren und 
zu den alten Modulen zuzulinken. Dies alles übernimmt Make. 

Sie müssen allerdings vorher dieses Tool (zu deutsch Werkzeug 
und im übertragenen Sinn Hilfsprogramm) in das Unterverzeich¬ 
nis c der Diskette sysl: kopieren. 
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Sie brauchen jetzt nur noch das Make-File zu erstellen, daß sich 
im aktuellen Verzeichnis befinden muß. Betrachten wir dazu 
einmal folgende Module: 

mod1.c 


funcK) 

pn'ntf ("Funktion 1 ruft Funktion 3 auf !\n"); 
func3(); 

> 

mod2.c 


func2() 
i 

printf ("Funktion 2 wird von Funktion 3 aufgerufen !\n");> 


mocB.c 


func3() 

i 

printf ("Funktion 3 ruft Funktion 2 auf !\n"); 
func2(); 

> 

main.c 

mainO 

C 

printf ("MAIN ruft Funktion 1 auf !\n"); 
funcK); 

> 

Das Make-File beschreibt nun, wie die einzelnen Files vonein¬ 
ander abhängen. So hängt z.B. das Objekt-File modl.o vom 
Source-File modl.c ab. Dies äußert sich in der Zeile modl.o: 
modl.c, was nichts anderes besagt, als daß die Befehle, die in 
der nächsten Zeile folgen, nur ausgeführt werden sollen, wenn 
modl.c älter als modl.o ist, oder wenn modl.o noch gar nicht 
existiert. 

Um festzustellen, welches File älter als ein anderes ist, müssen 
natürlich die Uhrzeit und das Datum richtig eingestellt worden 
sein. Das passiert ja in der Startup-Sequenz mit dem Aufruf von 
setdat. Da immer das Datum der letzten Änderung eines Files 
mit abgespeichert wird, kann Make immer feststellen, wie alt ein 
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File ist. Die Uhrzeit muß immer korrekt eingestellt sein, um zu 
verhindern, daß bei einer Änderung ein falsches Datum mit dem 
Files abgespeichert wird. 

Doch zurück zum Make-File. Die erste Zeile unseres Make-Files 
lautet also so: 

modl.o: mod.c 

In der nächsten Zeile folgt nun, was geschehen soll, wenn 
modl.o älter ist als modl.c: 

cc modi 

.Wenn modl.o älter ist als modl.c - also nach dem letzten Com- 
pilier-Vorgang eine Änderung an modl.c vorgenommen wurde, 
wird dafür gesorgt, daß das neue Objekt-File zu modl.c erzeugt 
wird (man sagt auch, daß mod.o ”upgedated” wird). 

Das Kommando, das nach einer solchen File-zu-File-Beziehung 
(modl.o: modl.c) ausgeführt werden soll, muß mindestens ein 
Zeichen eingerückt werden. Das Make-File, daß aus den vier C- 
Sources (s.o.) die zugehörigen Objekt-Files erzeugt, sieht also 
wie nachfolgend aus: 

modl.o: modl.c 
cc modi 

modZ.o: modZ.c 
cc mod2 

mocß.o: mod3.c 
cc mod3 

main.o: main.c 
cc main 

Solch ein Make-File kann ganz einfach mit dem Editor ED er¬ 
stellt werden. Es muß unter dem Namen "makefile" im aktuellen 
Verzeichnis vorliegen. Um aber z.B. dafür zu sorgen, daß ein 
Objekt-File "upgedated" wird, kann man Make wie folgt auf ru¬ 
fen; 


make main.o. 

Dieser Aufruf von Make sorgt dafür, daß im Bedarfsfälle das 
Objekt-File zu main.c erzeugt wird. Doch nützen einem die 
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einzelnen Objekt-Files ungelinkt gar nichts. Deshalb hängt man 
an das Make-File noch folgende Zeilen an: 

func: modl.o mod2.o mod3.o main.o 
ln -o func modl.o mod2.o mod3.o main.o -IRAMic 

Diese beiden Zeilen besagen einfach, daß das File func, welches 
das lauffähige Programm darstellt, von den vier Objekt-Files 
abhängig ist und daß, falls eines dieser Objekt-Files jüngeren 
Datums als func ist, das File func neu zusammengelinkt wird. 

Make untersucht auch jedes der Objekt-Files, und wenn Make 
feststellt, daß zwischenzeitlich eine Änderung an einem Modul 
vorgenommen wurde, erzeugt es das neue Objekt-File zum ge¬ 
änderten C-Source, so daß das Programm func immer auf dem 
neuesten Stand ist. 

Nun noch einmal das komplette Make-File, das durch den Auf¬ 
ruf make func das lauf fähige Programm erzeugt: 

modl.o: modl.c 
cc modi 

mod2.o: mod2.c 
cc mod2 

mod3.o: mod3.c 
cc mod3 

main.o: main.c 
cc main 

func: modl.o mod2.o mod3.o main.o 
ln -o func modl.o mod2.o mod3.o main.o -lRAM:c 

Das waren die einfachen Funktionen von Make. Doch wenn man 
das Make-File so ändert, daß der Linker-Aufruf (die letzten 
beiden Zeilen) in die erste Zeile geschrieben werden, braucht 
man gar nicht mehr make func aufzurufen, sondern kann sich 
auf Make beschränken. Bei einfachem Aufruf von Make wird 
nämlich das erste Kommando des Make-Files ausgeführt. 

Wollen Sie mehrere Kommandos nach einer File-zu-File-Bezie- 
hung ausführen, müssen Sie darauf achten, daß alle Kommandos 
mindestens eine Zeile eingerückt sind. Sonst brauchen Sie ei¬ 
gentlich nur noch auf den korrekten Aufruf der Befehle zu 
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achten, wobei Sie jedes beliebige CLI-Kommando (z.B. cd, de- 
lete etc.) verwenden können, z.B; 

func: modl.o mod2.o mcxß.o main.o 
ln -o func modl.o modZ.o mocB.o main.o -IRAMic 
delete modl.o 
delete mod2.o 


Eine weitere Möglichkeit von Make ist die Macro^Definition. In 
unserem Make-File kommt zweimal der String modl.o mod2.o 
mod3.o main.o vor. Wenn man diesen nun zu Beginn des Make- 
Files als Macro definiert, braucht man den String nur einmal 
explizit zu schreiben. Dies kommt besonders Programmen mit 
sehr vielen Modulen zu gute: 

OBJECT = modl.o modZ.o modS.o main.o 

func: $(OBJECT) 
ln -o func $(OBJECT) -IRAMic 


Man muß nicht immer den gleichen String mehrmals schreiben. 
Paßt der Macro-String aber einmal nicht mehr in eine Zeile, so 
können Sie diesen genauso wie in C-Programmen mit dem Back- 
Slash (\) "verlängern": 

OBJECT = modl.o mod2.o mod3.o mod4.o modS.o mod6.o\ 
modZ.o modS.o mod9.o modIO.o main.o 

Sie können nun eigene C-Programme mittels Make schreiben. 


1.2.4 Die Commercial-Version 

Der Vollständigkeit halber wollen wir Ihnen noch kurz die 
Commercial-Version des Aztec-Compilers vorstellen. Diese un¬ 
terscheidet sich von der Developers-Version nur darin, daß auf 
einer vierten Diskette die einzelnen Betriebssystemaufrufe aller 
Funktionen als Assembler-Source vorliegen. Einige Support- 
Funktionen für den Betrieb der Devices werden als C-Prozedu- 
ren angegeben. 
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Die meisten Maschinensprache-Aufrufe sind folgender Form; 

movem.l 4(sp), dO ;Parameter vom Stack holen 

... ;Rücksprungadresse! 

move.l #CBasePointer],a6 ;Library-Base in Register 

jsr _LV0Function(a6) ;Funktion aufrufen 

rts 

Es gibt aber auch Routinen, die mit den Parametern noch kom¬ 
plizierte Berechnungen und Veränderungen durchführen. 

Vielleicht ein kleiner Tip für alle diejenigen unter Ihnen, die 
jetzt erst mit dem Gedanken spielen, den Aztec-Compiler käuf¬ 
lich zu erwerben: Überlegen Sie genau, inwieweit Sie das Be¬ 
triebssystem programmieren wollen und ob es notwendig ist, die 
Commercial-Version mit den meist gleichen Maschinensprache- 
Aufrufen zu kaufen. Normalerweise tut es die Developers-Ver¬ 
sion nämlich auch, und der sehr große Kostenunterschied (na¬ 
hezu DM 500) darf nicht vergessen werden - zumal die arc-Files 
der Commercial-Version nicht von besnders hohem Ge¬ 
brauchswert sind. 


1.4 Der Compiler in Aktion 

Bevor wir nun aber zur Funktionsweise des Compilers kommen, 
wollen wir diesen ein wenig benutzen und auf einige Eigenarten 
hinweisen. 


1.4.1 Files vergleichen 

Als Einstieg in die Aztec-Programmierung soll uns ein Pro¬ 
gramm dienen, das zwei Files miteinander vergleicht und die 
Unterschiede sowie die Position, an der ein Unterschied auf tritt, 
anzeigt. Dazu muß dem Programm zunächst mitgeteilt werden, 
welche Files es vergleichen soll. Dies wird über die sogenannte 
Kommandozeile bzw. über die Kommando-Parameter getan. Die 
Parameter der Kommandozeile werden dem Programm über die 
Parameter der Funktion main() mitgeteilt: 
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main (arge, argv) 
int arge; 
ehar **argv; 

C...> 

arge (argument counter) enthält die Anzahl der angegebenen 
Parameter. Dabei muß man beachten, daß der Name des Pro¬ 
gramms auch als Parameter angesehen wird. Ist arge also gleich 
2, so wurde tatsächlich nur ein Parameter angegeben. 

Über den Zeiger argv kann man auf die Parameter (-Strings) 
zugreifen. Interessant ist es, sich diesen Zeiger einmal genau 
anzusehen: 

char **argv; 

Dieses Gebilde stellt nämlich einen Zeiger auf einen Zeiger vom 
Typ "char" dar. Zeiger vom Typ char sind aber nichts anderes 
als Zeiger auf Strings. Aufgrund der engen Verwandtschaft von 
Array und Zeiger kann man auf die einzelnen Parameter mittels 
argv[l], argv[2] etc. zugreifen. argv[l] ist die Adresse des ersten 
Parameterstrings. argv[0] enthält die Adresse des Pro¬ 
grammnamenstrings. (Man kann char **argv; auch durch char 
’'‘argv[]; ersetzen, was den Array-Zugriff auf die Parameter¬ 
strings verdeutlicht.) 

Nun müssen wir testen, ob auch tatsächlich die korrekte Anzahl 
Parameter übergeben wurde. In unserem Beispiel benötigen wir 
zwei Parameter - nämlich die beiden File-Namen der Files, die 
verglichen werden sollen, arge muß also den Wert 3 haben (Pro¬ 
grammnamen beachten!). Stellen wir eine Abweichung fest, wird 
eine Nachricht an den Benutzer ausgegeben, die ihm kurz er¬ 
klärt, welche Parameter der Aufruf enthalten muß: 

if (arge != 3) 

printf ("USAGE: compare FILE1 FILE2 \n"); 
exit (10); 

> 

Guter Stil wäre es, auch auf ein ? als Parameter zu reagieren, 
einen Benutzungshinweis zu geben und dann die geforderten 
Parameter direkt von der Tastatur einzulesen. Diese Option wird 
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von vielen CLI-Befehlen unterstützt, doch ist für unser kleines 
Programmbeispiel dieser Aufwand ungerechtfertigt. 

Die Parameter-Strings stehen uns also in argv[l] und argv[2] zur 
Verfügung (argv = argument values). Diese Strings können wir 
als Parameter für den C-Lib-Befehl fopen() verwenden. 

fopenO benötigt neben dem File-Namen des zu öffnenden Files 
noch einen zweiten Parameter, der angibt, wie auf das File zu¬ 
gegriffen werden soll, fopen (Name, "r") öffnet ein bestehendes 
File, um dieses zu lesen, während fopen (Name, "w") ein neues 
File erzeugt, das nur beschrieben werden kann. 

In unserem Beipiel kommt nur der Zugriff auf bestehende Files 
in Frage: 

Fi lei = fopen (argv[1] 

File2 = fopen (argv[2] ,*'r**); 

Nun wurde also versucht, die beiden zu vergleichenden Files zu 
öffnen. Da es aber nicht ausgeschlossen ist, daß sich der Benut¬ 
zer bei der Angabe der zu vergleichenden Files irrt und eines 
dieser Files vielleicht gar nicht existiert, sollte man testen, ob 
fopenO die Files auch tatsächlich öffnen konnte: 

if (Filei == OL) 

( printf ("%s kann nicht eröffnet werden !!!\n",argv[1]); 

Closelt (10); 

> 

if (File2 == OL) 

{ printf ("%s kann nicht eröffnet werden I!!\n",argv[2]); 

Closelt (10); 

> 

Sie wundern sich vielleicht, warum in der Bedingung Filel == 
OL der Buchstabe L hinter der 0 steht. Dies teilt dem Compiler 
mit, daß er den Zeiger Filel mit einem Long-Wert vergleichen 
soll. Man könnte dieses OL auch durch "(long) 0" ersetzen. Doch 
ist dies auf die Dauer ein wenig lästig. 

Es existiert allerdings eine weitere Möglichkeit, dafür zu sorgen, 
daß Konstanten als "Long-Variablen" aufgefaßt werden: die 



Die Sprache C 


31 


Compiler-Option +L. Hierbei ist allerdings darauf zu achten, daß 
auch die Int-Variablen, also nicht nur die Konstanten, zu Long- 
Variablen konvertiert werden. Sie sollten in Verbindung mit der 
Option +L allerdings die c32.1ib zum Programm linken, da nur 
hier dafür gesorgt werden kann, daß der Argument-Counter 
(arge) von main(argc,argv) tatsächlich eine Long-Variable ist. 

Greifen Sie bei Verwendung der c.lib und der Option +L auf 
diesen Zähler zu (z.B. if (arge == 3)), so werden ja 4 anstatt nur 
2 Bytes für die Angabe des Wertes dieser Variablen benutzt. 
Dies verfälscht das Ergebnis aber in fatalem Maße, da die bei¬ 
den Bytes der vorigen Int-Variable nun die beiden höherwerti¬ 
gen Bytes der Jetzigen Long-Variablen (+L-Option) sind und die 
Zeiger auf die Strings um jeweils zwei Bytes verschoben werden. 

Doch zurück zum eigentlichen Problem: Ist der von fopen() zu¬ 
rückgegebene Filedeskriptor gleich 0, liegt ein Fehler bei der 
Öffnung des Files vor. Dann wird eine Routine angesprungen 
(CloseltO), die dafür sorgt, daß vorher geöffnete Files geschlos¬ 
sen werden, eine Nachricht an den Benutzer ausgegeben und das 
Programm verlassen wird. (Ein kleiner Tip: Programme, die z.B. 
Speicherbereiche belegen oder andere Operationen vornehmen, 
die wieder rückgängig gemacht werden müssen, sollten eine 
Routine zur Verfügung stellen, die automatisch alles das, was 
erfolgreich belegt werden konnte, wieder freigibt. Dies spart 
Programmierarbeit.) 

Wenn die Files aber ordnungsgemäß geöffnet werden konnten, 
können wir uns mit dem Vergleich der beiden Files beschäfti¬ 
gen. Jetzt folgt die Hauptschleife unseres Programms, die die 
beiden Files Byte für Byte nach Gemeinsamkeiten bzw. Unter¬ 
schieden durchsucht. 

Dazu wird aus beiden Files das jeweils nächste Byte gelesen, und 
diese beiden Bytes werden dann verglichen. Sind die Bytes iden¬ 
tisch, werden die nächsten beiden Bytes gelesen. Bei unter¬ 
schiedlichen Bytes werden die beiden gelesenen Bytes ausgege¬ 
ben, und die Position innerhalb der Files, an der der Unter¬ 
schied aufgetreten ist, erscheint auch. 
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Am besten ist es, wenn man die beiden Files innerhalb einer 
While-Schleife untersucht, die dann abgebrochen wird, wenn ei¬ 
nes der beiden Files vollständig gelesen wurde. Das Ende eines 
Files wird mit Hilfe der Funktion feof() festgestellt, und mit 
fgetc kann man das jeweils nächste Byte des Files lesen. 

fllepos = 0; 

while (!feof(File1) && !feof(File2)) 

C 

Byte1 = fgetcCFiIe1); Byte2 = fgetc(File2); 
if (Byte1 != Byte2) printf ("$%08x %02x <> %02x\n", 
fllepos,Byte1,Byte2); 
fllepos++; 

> 

In dieser Schleife werden immer die beiden gelesenen Bytes 
(Bytel und Byte2) miteinander verglichen, und bei einem Un¬ 
terschied wird z.B. folgender Text ausgegeben: 

$00000154 $12 <> $3a 

Neben den sich unterscheidenden Bytes wird auch ausgegeben, 
an welcher Stelle der Unterschied aufgetreten ist. Dies macht es 
allerdings nötig, eine Zählvariable (filepos) "mitlaufen" zu lassen, 
die die Anzahl der eingelesen Bytes bzw. die Leseposition inner¬ 
halb des Files enthält. 

Nach dem Vergleich wird diese Zählvariable um eins inkremen- 
tiert, und wenn in beiden Files noch Daten enthalten sind, wird 
mit dem Vergleich fortgefahren. Enthält aber eines der beiden 
Files keine Daten mehr, wird die Schleife verlassen. 

Die File-Statistik, die angibt, wie viele Bytes die einzelnen Files 
enthalten, wird durch folgende Programmsegmente erzeugt: 

if (feof(Filel) && !feof(File2)) /• Fllel enthält keine Daten V 

/• mehr, aber File2. */ 

{ 

printf ("Comparison terminated M!\n"); 

printf ("%s out of data at %08lx\n",argv[1],filepos-1); 

while (!feof<File2)) 

i 

fgetc (File2); 
filepos++; 

> 
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printf ("%s out of data at %08lx\n",argv[2] ,filepos-l); 

> eise 

if (!feof(FiIe1) && feof(FTle2)) /* File2 enthält keine Daten V 

/* mehr, aber Fi lei. V 

C 

printf ("Comparison terminated M!\n'*); 

printf ("%s out of data at %08lx\n",argv[2] ,filepos-1); 

while (!feof(Fi lei) 

<; fgetc(Fi lei ); 

filepos++; 

> 

printf ("%s out of data at %08lx\n",argv[1] ,filepos-1); 


Die beiden If-Anweisungen testen, welches File vollständig ge¬ 
lesen wurde. Im jeweiligen Rumpf wird dann der Name des 
vollständig gelesenen Files und dessen Länge ausgegeben. Das 
jeweils andere File wird bis zum Ende gelesen und für jedes 
gelesene Byte wird der filepos-Zähler erhöht. Nachdem das 
Ende des Files erreicht wurde, wird auch dieser File-Name so¬ 
wie die Länge des Files ausgegeben: 

Coinparison terminated !M 

File1 out of data at $00000170 

FileZ out of data at $00000200 

Noch ein paar Worte zum filepos-Zähler. In der ersten While- 
Schleife, in der der Vergleich der beiden gelesenen Bytes aus¬ 
geführt wird, wird filepos immer erhöht, wenn eines der beiden 
Files noch Bytes zur Verfügung stellt. Testet man aber mit feof() 
das Ende eines Files, so wird von fgetc() innerhalb der Schleifen 
immer ein Byte mehr als tatsächlich vorhanden gelesen. (Dies ist 
übrigens auch die Ursache dafür, daß beim Vergleich verschie¬ 
den langer Files ein Byte mehr "verglichen" und evtl, ausgegeben 
wird.) Wir müssen also dafür sorgen, daß dieses "Byte zuviel" bei 
der Ausgabe der Größe von filepos abgezogen wird. 

Haben beide Files die gleiche Länge, wird dies durch folgende 
If-Anweisung festgestellt. 

(eise) 

if (feof(Filel) && feof(File2)) 

printf ("\‘'%s\" and \"%s\" have got the size: %08lx'', 
argvtl] ,argv[2] ,f i lepos-1); 
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Es erfolgt dann z.B. folgende Ausgabe: 

FILE1 and FILE2 have got the size: $00000123 

Nun muß nur noch dafür gesorgt werden, daß die geöffneten 
Files geschlossen werden und das Programm verlassen wird. Dies 
wird durch einen Aufruf der schon oben erwähnten Routine 
CloseltO erreicht: 

Closelt (Error_Code) 
int Error Code; 
i 

if (Filel != 0) fclose (Filel); 
if <File2 != 0) fclose (File2); 
exit (Error Code); 

> 

Diese Routine sorgt daür, daß die geöffneten Files geschlossen 
werden (File-Deskriptor != 0) und das Programm über exit() ab¬ 
gebrochen wird. Der Error_Code, der exit() übergeben wird, 
wird an das CLI weitergeleitet und kann so z.B. in Batch-Files 
dafür sorgen, daß das Batch-File abgebrochen wird (FAILAT). 

Hier aber das komplette Programm, in dem auch alle verwende¬ 
ten Variablen definiert werden: 


/* COMPARE */ 
/* (c) Bruno Jennrich */ 
/* */ 
/* */ 


/* Dieses Programm vergleicht zwei Files miteinander. */ 

y*****4r***************4r*****************************4r*** j 

#include "stdio.h" 


FILE *File1, /* File-Deskriptoren */ 

*File2; 

long filepos; /* Aktuelle File-Position */ 

unsigned char Bytel, /* gelesenes Byte */ 

Byte2; 

mein (arge, argv) 
int arge; 
char **argv; 

C 


if (arge != 3) 
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{ 

printf ("USAGE: compare FREI FILE2 \n"); 
exit (10); 


Fl lei = fopen (argvCl],"r"); /* Files öffnen */ 

File2 = fopen (argv[2],"r"); 

if (Fl lei == OL) /* File-OpenO Error */ 

C 

printf ("%s kann nicht eröffnet werden !!!\n",argv[1]); 
Closelt (10); 


if (File2 == OL) /* File-OpenO Error */ 

i 

printf ("%s kann nicht eröffnet werden !!!\n",argv[2]); 
Closelt (10); 


filepos = 0; /* Aktuelle File-Position = 0 */ 

while (!feof(File1) && !feof(File2)) 
i 

Bytel = fgetc (Fi lei); /* Bytes lesen */ 

Byte2 = fgetc (File2); 

if (Bytel != Byte2) /* Unterschied ausgeben 

printf ("$%08lx $%02x <> $%02x\n'', f i lepos,Bytel ,Byte2); 
filepos-»-+; /* Fi le-Position erhöhen */ 

} 

if (feof(Filel) && !feof(File2)) /* Fi lei enthält keine */ 

/* Daten mehr, aber File2. */ 

{ 

printf ("Comparison terminated !!!\n''); 

printf ("\"%s\" out of data at $%08lx\n'',argv[1],f i lepos-1 ); 
while (!feof(File2)) 
i 

fgetc (File2); 
filepos++; 

> 

/* File zuende lesen */ 

printf ("\"%s\" out of data at $%08lx\n",argv[2] ,filepos-1); 

> 

eise 

if (!feof(Fi lei) && feof(File2)) /* File2 enthält keine */ 

/* Daten mehr, aber Fi lei. */ 
i 

printf ("Comparison terminated !!!\n"); 

printf ("\"%s\" out of data at $%08lx\n",argv[2],filepos-1); 
while (!feof(Fi lei)) 

fgetc (Fi lei); 
filepos++; 

} 
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/* File zuende lesen */ 

printf ("\"%s\“ out of data at $%08lx\n",argv[1],filepos-1); 

> 

eise 

if (feof(Filel) && feof(File2)) 

printf ("\"%s\" and \"%sV' have got the size: %08lx\n", 
argvCI],argv[2],filepos-1); 

Closelt (0); 

> 

Closelt (Error_Code) 
int Error_Code; 

C 

if (Fi lei != 0) fclose (Fi lei); 
if (File2 != 0) fclose (File2); 
exit (Error_Code); 

> 

Da dieses Programm aus einem einzigen Modul besteht, lohnt es 
sich nicht, dafür extra ein Make-File anzulegen. Ein Batch-File 
tut es hier auch; 

.key f i le 
cc <file> 

ln +Cb -o<file> -Lram:c 

Dieses Batch-File kann (und sollte) übrigens für alle in den Ka¬ 
piteln 1 und 2 enthaltenen Programme verwendet werden. 

Die von diesem Batch-File erzeugten Programme werden immer 
in den Chip-Memory des Rechners geladen. Auch wenn Sie 
mehr als 512 KByte Speicher haben sollten, wird das Programm 
in diesen unteren 512 KByte angesiedelt (wenn dort noch Spei¬ 
cher frei ist). 

Sollten Sie einmal ein Programm verfassen, das nicht mit dem 
noch freien Chip-Speicher auskommt (beim 1000er ca. 320 
KByte), so können Sie das Programm ohne die +Cb-Option lin¬ 
ken, müssen dann aber dafür sorgen, daß die Strukturen, die 
unbedingt unterhalb der 512-KByte-Grenze liegen müssen, auch 
dort liegen (z.B. Speicherzuweisung für Strukturen: *Zeiger_ 
auf_Struct = AllocMem (sizeof (struct ...), MEMF_CHIP)). 
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1.4.2 Hexdump eines Files 

Das obige Programm läßt sich leicht so umschreiben, daß es 
einen Hexdump eines Files ausgibt. Ein "Hexdump” ist eine Aus¬ 
gabe folgender Form: 

$00000000 $61 $62 $63 $64 $65 $65 $66 $67 $68 abcdefghi 

$00000009 $69 j 

Es werden also die augenblickliche Leseposition (erste Spalte), 
die hexadezimale Repräsentation der gelesenen Zeichen (zweite 
Spalte) und die einzelnen gelesenen Zeichen als ASCII-Zeichen 
ausgegeben. 

Das Programm muß zunächst so modifiziert werden, daß nur ein 
einziges File geöffnet wird. Vorher muß allerdings auch hier die 
korrekte Anzahl der übergebenen Parameter getestet werden: 

main (arge, argv) 
int argv; 
char *argv[]; 

i 

if (arge != 2) 
i 

printf ("USAGE: dump FILE \n»); 
exit (10); 

> 


__File = fopen (argvCl] ,"r"); 

if ( File == 0) 
i 

printf ("\''%s\" kann nieht eröffnet werden M!\n'', 
argvCl] ); 

Closelt (10); 

> 


> 

Dies ist Ihnen ja schon aus dem obigen Programm bekannt. Was 
nun aber neu ist, ist der Aufbau einer "Conversion_Table": 

for (i=0;i<32 ;i■»••«•) Conversion_TableCi] = 

for ( ;i<128;i++) Conversion_Table[i] = (ehar)i; 

for ( ;i<160;i++) Conversion_TableCi] = 

for ( ;i<256;i++) Conversion_Table[i3 = (ehar)i; 
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Diese "Conversion_Table" wird für die Ausgabe der gelesenen 
Bytes als Zeichen benötigt. Man kann nämlich nicht alle ASCII- 
Codes ausgeben. Der ASCII-Code 12 sorgt zum Beispiel dafür, 
daß der Bildschirm gelöscht wird. Damit dies oder ähnliches 
nicht passiert, werden in einer Tabelle alle druckbaren Zeichen 
abgespeichert. Die Zeichen, die nicht ausgegeben werden können 
- das sind die ASCII-Codes von 0-31 und von 128-159 - werden 
durch einen Punkt repräsentiert (siehe AmigaBASIC-Handbuch, 
dort Anhang A). 

Um diese Tabelle aufzubauen, verwenden wir vier For-Schlei- 
fen. Eine Besonderheit dabei ist, daß wir bei den drei letzten 
For-Schleifen auf die Initialisierung der Lauf variablen i ver¬ 
zichten. Dies ist auch gar nicht nötig. Nach jeder FOR-Schleife 
hat die Laufvariable i immer den Wert, den die Variable für die 
Abarbeitung der nächsten For-Schleife enthalten muß. 

Nun können wird die einzelnen Bytes lesen, nicht ohne vorher 
die File-Position auf 0 zu setzen: 

filepos = 0; 

while ((ok = Liest)) != 0) 
t 

printf ("$%08lx ".filepos); 
filepos += ok; 

for (i=0;i<ok;i++) printf ("$%02x ",Byte[i)); 
printf (" "); 

if (ok < WIDTH) for ( ;i<WIDTH;i++) printf (" "); 

for (i=0;i<ok;i++) 

printf ("%c",Conversion_Table[Byte[i]]); 
printf ("\n"); 

> 

In der Bedingung der While-Schleife wird nun dafür gesorgt, 
daß Bytes aus dem File gelesen werden. Dazu wird die Routine 
Lies aufgerufen, die dafür sorgt, daß entweder WIDTH = 12- 
Bytes, oder die noch verbleibenden Bytes eines Files gelesen 
werden (plus eines, aufgrund der Tatsache, daß feof() erst dann 



Die Sprache C 


39 


wahr (TRUE) wird, wenn ein Zeichen mehr als das letzte gele¬ 
sen wurde). 

Über die Variable z wird die Anzahl der gelesenen Bytes zu¬ 
rückgegeben: 

int LiesO 
C 

int i; 
int z; 

for (i=0;i<WIDTH;i++) 
if (!feof( File)) 

C 

ByteCi] = fgetc<_File); 

Z++; 

> 

return(z); 

> 

width ist eine Konstante, die zu Beginn des Programms definiert 
wird. Sie gibt an, wie viele Bytes in einer Zeile dargestellt wer¬ 
den sollen. Im Probeausdruck zu Beginn dieses Kapitels ist width 
gleich 9. Bei der Ausgabe des Hexdumps auf ein 80-Zeichen 
breites CLI-Window kann width den Wert 12 haben. So wird die 
ganze Breite des Windows für die Ausgabe genutzt. 

Bei der Ausgabe des Hexdumps wird zunächst die File-Position 
ausgegeben (printf ("$%081x ",filepos);). Danach wird die File- 
Position um den Betrag der gelesenen Bytes erhöht (filepos += 
ok;). Das Ergebnis von Lies() ist nämlich die Anzahl der 
tatsächlich gelesenen Bytes (while ((ok = Lies()) != 0). 

Nach der Ausgabe der File-Position (und einiger Leerzeichen 
zur Spaltentrennung) muß nun jedes gelesene Byte in hexadezi¬ 
malem Format ausgegeben werden. Dies geschieht in einer FOR- 
Schleife (for (i=0;i<ok;i-H-) printf ("$%021x ", Byte[i]);). Hierbei 
belegen die hexadezimalen Zahlen zwei Zeichen. Den Zahlen 0 
bis f wird eine 0 als Füllzeichen vorangestellt. 

Ist nun die tatsächliche Anzahl gelesener Bytes kleiner als width, 
werden für die fehlenden Bytes Leerzeichen ausgegeben (if (ok 
< WIDTH) for (i=ok;i<WIDTH;i-H-) printf (" ");). Es kann 
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zwar nur am Ende des Files geschehen, daß nicht mehr width- 
Bytes gelesen werden können, aber dennoch sieht es nicht be¬ 
sonders professionell aus, wenn die Ausgabe der hexadezimalen 
Zahlen und der ASCII-Zeichen durcheinandergebracht wird, wie 
z.B. so: 

$00000000 $12 $23 $10 $07 $06 $07 $c2 $82 $85 . 

$00000009 $12 $23 $10 $07 $06 . 

Deshalb werden in der For-Schleife immer die gleiche Anzahl 
Leerzeichen ausgegeben, die von einer hexadezimalen Zahl "ver¬ 
braucht" werden. 

Danach brauchen nur noch die gelesenen Bytes als ASCII-Zei¬ 
chen ausgegeben zu werden (for i=0;i<ok;i++) printf ("%c", Con- 
version_Table[Byte[i]]);). Dazu wird die vorher aufgebaute 
"Conversion_Table" mit dem Wert der vorher gelesenen Bytes 
indiziert. Nach der Ausgabe der ASCII-Zeichen wird ein Car- 
riage Return ausgegeben (printf ("\n");), damit die weitere Aus¬ 
gabe in der nächsten Zeile erfolgen kann. 

Wird die While-Schleife verlassen (alle Bytes des Files wurden 
gelesen), müssen Sie nur noch dafür sorgen, daß das File wieder 
geschlossen wird. Dies wird durch Closelt(O) erreicht, wobei 
CloseltO diesmal so aussieht: 

Closelt (Error_Code) 
int Error_Code; 

C 

if (_File == 0) fclose (_File); 
exit (Error_Code); 

> 

Hier noch einmal das ganze Programm, auch wieder mit der 
Definition aller Variablen und Arrays: 

y *******************************************************! 


/* DUMP */ 
/* (c) Bruno Jennrich */ 
/* */ 
/* */ 
/* Dieses Programm erzeugt ein Hexdump eines Files. */ 


^‘Ar4rir4r*4r4r4r4r4r4rilr4r4nlr4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r4r$ir**W4r4r4r4r4r4r4r4r$lr j 

#include “stdio.h" 
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#define UIDTH 12L 


/* 12 Zahlen pro Zeile V 
/* 80-Zeichen Bildschirm */ 


FILE ♦^File; 
long filepos; 
unsigned char 
unsigned char 

int ok; 


/♦ Filedeskriptor */ 

/* Aktuelle File-Position */ 
BytelWIDTH]; /* Buffer für einzulesende Bytes V 
Conversion_TableC256]; 

/* ASCII - Printable conversion V 
/* Anzahl der gelesenen Bytes V 


int LiesO 

< 

int i; 
int z = 0; 


for (i=0;i<WIDTH;i++) 
if (!feof(_File)) 
f 

ByteCi] = fgetc(_File); 

Z++; 

> 

return (z); 

> 

main (arge, argv) 

int arge; 

char *argv[]; 

<: 

int i; /* Laufvariable */ 

if (arge != 2) /* zu wenig Parameter */ 

C 

printf ("USAGE: dump FILE \n*»); 
exit (10); 

> 


_File = fopen (argvCI],"r"); f* File öffnen */ 

if ( File == 0) I* File-Open Error V 

< 

printf (”\"%s\'' kann nicht eröffnet werden !!! \n*',argv[1] ); 
Closelt (10); 

> 

for (i=0;i<32 ;i-»-+) Conversion_Table[i3 = *.*; 

for ( ;i<128;i++) Conversion_Table[i] = (char)i; 

for ( ;i<160;i++) Conversion_Table[i] = 

for ( ;i<256;i+-»-) Conversion_Table[i] = (char)i; 

/* Conversion_Table aufbauen */ 

filepos=0; /♦ Aktuelle Fileposition gleich 0 V 

while ((ok = LiesO) != 0) 
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printf ("$%08lx '',filepos); 

/* Aktuelle File-Position ausgeben */ 
filepos+=ok; Aktuelle File-Position erhöhen V 

for (i=0;i<ok;i++) printf (*'S%02x '',ByteCi]); 

/* Hexadezimale Zahlen */ 

if (ok < WIDTH) for (i=ok;i<WlDTH;i++) printf (" •'); 

/* Evt. "Leer-Zahlen” */ 

printf (" '•); /* Spaltenabtrennung */ 

for (i=0;i<ok;i++) printf 

("%c",Conversion Table[Byte[i]]); 

/* “ASCII"-Darstellung V 

printf ("\n“); /* Carriage-Return */ 

> 

Closelt (0); /* Tschüs V 


Closelt (Error_Code) 
int Error_Code; 

C 

if (_File != 0) fclose (_File); /* Wenn File offen, */ 

/* File schliessen V 

exit (Error_Code); 

> 


1.4.3 Ein Monitor 

Die hexadezimale Ausgabe läßt sich durch kleinere Änderungen 
auch für einen Monitor benutzen. Mit einem Monitor ist es 
möglich, sich Speicherbereiche des Amiga anzusehen. Der Mo¬ 
nitor zeigt also die verschiedenen Speicherinhalte an. 

Dazu müssen Sie dem Programm die Anfangs- und Endadresse 
des Speicherbereichs mitteilen, der angezeigt werden soll. Auch 
dies geschieht wieder über die Kommando-Parameter. Diesmal 
werden wieder zwei Parameter übergeben: 

main (arge, argv) 
int arge; 

char "^''argv; 

C 

if (arge != 3) 

printf ("USAGE : mon ANFANG ENDE \n"); 
exit (10); 
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> 


> 

Nachdem abgeklärt wurde, daß die richtige Anzahl Parameter 
übergeben wurde, kann man nun beginnen, diese zu konvertie¬ 
ren. Die angegebenen Anfangs- und Endadressen liegen ja noch 
als ASCII-Strings vor und müssen deshalb in eine Zahl umge¬ 
wandelt werden. Wir haben uns entschieden, den String in eine 
hexadezimale Zahl umzuwandeln. Fast jeder Monitor arbeitet 
mit hexadezimalen Zahlen - also auch unser Monitor. 

Leider stellt uns der Compiler keine Routine zur Verfügung, die 
einen ASCII-String in eine Hex-Zahl wandelt. Diese müssen wir 
selber schreiben: 

unsigned char *atoh (String) 
char ^String; 

r 

int i; 

unsigned char *hex; 
unsigned long faktor; 

hex = (unsigned char *)0L; 
faktor = 1L; 

if (Strien (String) <= 8) 
for (i=(strlen(String)-1);i>=0;i--) 

C 

if ((StringCi] >= '0') && (StringCi] <= '9')) 
i 

hex += (StringCi] -’O*)*faktor; 
faktor *= 0x10; 

> 

if (((StringCi] & MASK) >= 'A») && 

((StringCi] & MASK) <= *F')) 
i 

hex += ((StringCi] & MASK) - •A'+Oxa)*faktor; 
faktor 0x10; 

> 

> 

return (hex); 

> 

Diese Routine setzt zunächst den Rückgabewert hex auf 0 und 
einen "faktor" auf 1. Die folgenden Schritte werden nur dann 
ausgeführt, wenn die Länge des eingegebenen Zahlen-Strings 8 
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Zeichen nicht überschreitet. Dies deshalb, weil der Adreßbereich 
von 4 Gigabytes, den der Amiga theoretisch adressieren kann, 
durch die Adressen 0 - ffffffff abgedeckt wird. Die höchste 
Adresse ist also ffffffff. Diese Zahl enthält als String aber nur 8 
Zeichen. 

Hat der eingegebene Zahlen-String weniger oder genau 8 Zei¬ 
chen, so wird die Hauptschleife dieser Routine ausgeführt. In 
dieser Schleife wird der String Zeichen für Zeichen betrachtet - 
allerdings wird mit dem letzten Zeichen des Strings begonnen 
und mit dem ersten aufgehört. 

In dieser Schleife wird bei der Initialisierung der Lauf variablen 
allerdings der Wert 1 von der Länge des Strings abgezogen (for 
(i=(strlen(String)-l);i>=0;i—)). Das geschieht, weil das erste 
Zeichen des Strings StringfO] und nicht String[l] ist. Damit wir 
bei den in der Schleife folgenden Zugriffen auf Zeichen des 
Strings nicht immer wieder den Wert 1 abziehen müssen, wird 
dies einmal zu Beginn der Schleife bei der Initialisierung der 
Laufvariablen getan. 

Innerhalb der Schleife werden nun zwei Fälle unterschieden: 

1. Das Zeichen des Strings ist eine Ziffer (0-9). 

2. Das Zeichen des Strings ist ein Buchstabe (A-F bzw. a-f). 

Bei der Berechnung des Ergebnisses wird nun getestet, ob das 
gerade aktuelle Zeichen des Zahl-Strings eine Ziffer (0-9) oder 
ein Hex-Zeichen (a-f) ist. 

Im ersten Fall wird vom ASCII-Wert der eingelesenen Ziffer der 
ASCII-Wert der Ziffer 0 abgezogen. Dies geschieht aus einem 
sehr einleuchtenden Grund: Durch diese Subtraktion erhält man 
nämlich den Zahlenwert, den diese Ziffer darstellt. "1 - 0" ergibt 
also den Zahlenwert 1. "2 - 0" ergibt den Zahlenwert 2 etc. 
Diese Zusammenhänge kann man sehr leicht aus einer ASCII- 
Tabelle (z.B. aus dem AmigaBASIC-Handbuch) ersehen. Der 
ASCII-Code der Ziffer 0 beträgt nämlich 48, der der Ziffer 1 
beträgt 49 und so weiter, bis zur Ziffer 9, die den ASCII-Code 
57 hat. 
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Die so erhaltene Zahl wird mit dem "faktor" multipliziert und 
zum bisherigen Ergebnis addiert. Darauf wird der "faktor" mit 
dem Wert 0x10 multipliziert. Die Muliplikation des Faktors mit 
0x10 = 16 kommt einer Stellenverschiebung gleich. 

Im Dezimalsystem bedeutet die Zahl 123 bekanntlich: 

3'Einer + 2 Zehner + 1 Hunderter 

Ähnlich sieht es bei Hexadezimal-Zahlen aus, nur daß hier die 
Zahl 16 und nicht die Zahl 10 als Basis gewählt wurde. Die he¬ 
xadezimale Zahl 123 bedeutet also: 

3 Einer -t- 2 Sechzehner + 1 Zweihundertsechsundfünfsiger 
Oder anders geschrieben: 

3 ♦ 0x1 + 2 * 0x10 + 1 ♦ 0x20 

"faktor" durchläuft nun der Reihe nach die Werte 0x1, 0x10, 
0x20 etc. Nun wird vielleicht auch klar, warum der String von 
hinten nach vorne durchgearbeitet wird. Der Computer weiß 
garantiert, daß das letzte Zeichen des Strings die Einer-Stelle der 
Zahl repräsentiert. Das vorletzte Zeichen steht an der Sech¬ 
zehner-Stelle, das dritte Zeichen an der 256er Stelle etc. 

Doch kommen wir zum zweiten Fall. Hier werden die Hex-Zif- 
fern a-f untersucht. Da wir nicht davon ausgehen, daß Sie nur 
Klein- oder nur Großbuchstaben verwenden, konvertieren wir 
die Zeichen zunächst in Großbuchstaben. Dies geschieht durch 
Ausblendung des Bits 4. (String[i] & MASK" = "String[i] & 
(255L-32L)) (siehe ASCII-Tabelle). Von der gerade zu bearbei¬ 
tenden Hex-Ziffer wird der ASCII-Wert des Zeichens A ab¬ 
gezogen, um auch hier die Werte 0, 1, 2 etc. zu erhalten. Da die 
Zahl A aber den Wert Oxa sprich 10 darstellt, muß zum er¬ 
haltenen Wert noch der Wert Oxa addiert werden. Mit der Be¬ 
rechnung des Ergebnisses kann wie oben fortgefahren werden. 

Die Anfangs- und Endadressen, die den anzuzeigenden 
Speicherbereich bestimmen, können nun mittels dieser Funktion 
errechnet werden: 
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lowadress = atoh (argvCI]); 
highadress = atoh (argv[2]); 

Beachten sollten Sie, daß Zeichen, die weder Ziffer noch Hex- 
Zeichen sind, nicht berücksichtigt werden. Der Zahl-String 
12$$5 liefert den gleichen Wert wie 125. 

Nun wird getestet, ob die Anfangsadresse kleiner als die 
Endadresse des zu durchleuchtenden Speicherbereichs ist. Der 
Speicher wird nämlich in aufsteigender Reihenfolge bearbeitet: 

if (lowadress > highadress) 

( 

printf ("ANFANG muB kleiner als ENDE sein !\n”) 
exit (10); 

> 

Wenn die Anfangsadresse größer als die Endadresse ist, wird das 
Programm sofort verlassen. Ist es jedoch so, daß die Anfangs¬ 
adresse kleiner als die Endadresse ist, können wir die aus obi¬ 
gem Programmbeispiel (s. dump) bekannte Conversion_Table 
aufbauen: 

for (i=0;i<32 ;i+*) Conversion_Table[i] = 

for ( ;i<128;i++) Conversion_Table[i] = (char)i; 

for ( ;i<160;i++) Conversion_Table[i] = 

for ( ;i<256;i++) Conversion_Table[i] = (char)i; 

Ähnlich wie wir mit filepos in den oberen Programmen gear¬ 
beitet haben, um die aktuelle File-Position darzustellen, arbeiten 
wir hier mit der Variablen pos, die die Adresse der jeweils 
auszugebenden Speicherstelle enthält. Zu Beginn erhält diese den 
Wert von lowadress: 

pos = lowadress; 

Nun können wir mit der Darstellung der Speicherinhalte begin¬ 
nen. Doch diese sollte man innerhalb einer weiteren Routine 
ausgeben, da wir hier selber testen müssen, wann die Ausgabe 
beendet werden soll. 

Beim Hexdump eines Files war dies nicht so schwer, da uns die 
Funktion Read() mitgeteilt hat, ob wir das File weiter auslesen 
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konnten oder nicht. Read() hat uns auch mitgeteilt, wie viele 
Bytes wir ausgeben mußten. 

Die Anzahl der jeweils noch auszugebenden Zeichen müssen wir 
selber berechnen. Dies ist gar nicht schwer: 

uidth s WIOTH; 

while (pos < highadress) 

if ((highadress-pos) >= width) Show (WIDTH); 
eise Show (highadress-pos); 

Solange der Wert von pos die Adresse der höchsten auszuge¬ 
benden Speicherstelle nicht erreicht hat, werden Bytes ausgege¬ 
ben. Dabei wird unterschieden, ob noch so viele Bytes ausgege¬ 
ben werden sollen, wie in eine Zeile passen (Show (width)), oder 
weniger. 

Ist die Anzahl der auszugebenden Bytes kleiner als die Anzahl 
der Bytes, die in einer Zeile dargestellt werden können (width), 
so werden nur noch die tatsächlich darzustellenden Bytes darge¬ 
stellt (Show (highadress-pos)) - kein Byte mehr und kein Byte 
weniger. 

Um allerdings zu testen, ob nur noch wenige (weniger als width) 
Bytes auszugeben sind, muß man die Anzahl der auszugebenden 
Bytes (highpos-pos) mit der Anzahl der Bytes, die in einer Zeile 
dargestellt werden können, vergleichen. Leider versteht es der 
Aztec-Compiler nicht, Long-Konstanten (z.B. 12L) auch im 
Vergleich als Long-Konstanten anzusehen (Eine Ausnahme bil¬ 
det das ==, bei dem Long-Konstanten nicht verarbeitet werden). 
Bei Zuweisungen und als Parameter von Prozeduren werden 
Long-Konstanten korrekt behandelt. 

Wir haben uns deshalb einen Trick einfallen lassen: Wir weisen 
einfach den Wert der Konstanten einer Long-Variablen zu und 
verwenden diese Variable beim Vergleich. Dies versteht der 
Compiler. (Bei Verwendung der +L-Option und der c32.1ib 
brauchen Sie diesen Trick nicht anzuwenden.) 

Nun aber zu der Routine, die für die Ausgabe der Bytes auf 
dem Bildschirm verantwortlich ist. Sie ist Ihnen, wie oben schon 
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erwähnt, im großen und ganzen bekannt. Wir haben nur ein paar 
kleine Änderungen vorgenommen: 

Show (ok) 
long ok; 

int i; 

printf ("$%08lx ",pos); 

for (i=0;i<ok;i++) 

printf("S%02x ",*(pos+i)); 

if (ok < WIDTH) for ( ;i<WIDTH;i++) printf (" "); 

printf (" "); 

for (i=0;i<ok;i++) 

printf <"%c",Conversion_Tablet*(pos++)l; 
printf ("\n"); 

> 

Diese Routine gibt zunächst die Adresse des ersten dargestellten 
Bytes einer Zeile aus. Dann wird jedes Byte - wie oben schon - 
in hexadezimaler Notation ausgegeben. Auch daß bei einer klei¬ 
neren Anzahl auszugebender Bytes Leerzeichen ausgegeben wer¬ 
den, um die ASCII-Zeichen tatsächlich in einer Spalte ausgeben 
zu können, ist schon bekannt. 

Neu ist allerdings der Zugriff auf pos. Auf diese Variable - oder 
vielmehr Zeiger - wird zunächst mit *(pos+i) zugegriffen. Dies 
bedeutet nichts anderes als: Addiere zur aktuellen Adresse von 
pos den Wert i, und gib dann den Inhalt dieser neuen Adresse 
zurück. 

Ähnlich ist es mit *(pos-H-). Dies heißt allerdings: Inkrementiere 
die Adresse, auf die pos zeigt, und liefere den Inhalt dieser 
neuen Adresse zurück. 

In beiden Fällen sind die Klammern nötig. * hat eine größere 
Priorität als ++. Würde man die Klammern weglassen, hätte 
*(pos++) die Bedeutung: Hole den Inhalt der Speicherstelle, auf 
die pos zeigt, und inkrementiere diesen Wert (*pos++). 
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Hier noch einmal das komplette Programm: 


y*******************************************************^ 


HON 

(c) Bruno Jennrich 


/* 

/* 

/* 

/* 

/* Dieses Programm gibt einen Speicherbereich als 
/* Hexdump aus. 

y*******************************************************^ 


*/ 

*/ 

*/ 

*/ 


#define WIDTH 12L /♦ Anzahl darzustellender Bytes V 

#define MASK (255L-32L) /* für Konvertierung in Groß- V 

/* buchstaben. V 


unsigned char Conversion_TableC256]; 

/* Conversion Tabelle */ 

unsigned char *lowadress, /* kleinste darzustellende Adresse V 
♦highadress; größte darzustellende Adresse */ 

unsigned char *pos; /* aktuelle Adresse, bzw. Position V 

/* im Speicher. V 


unsigned char *atoh (String) /* Ziffern-String nach Hex */ 
char *String; 

< 

i nt i ; 

unsigned char *hex; /* Ergebnis V 

unsigned long faktor; /* Stellenfaktor */ 


hex = (unsigned char *)0L; f* Ergebnis = 0 V 

faktor = 1L; /* Faktor gleich 1 (Einer Stelle) ♦/ 

if (Strien (String) <= 8) /* mehr als 8 Zeichen */ 

for (i=(strlen(String)-1);i>=0;i--) 

C 

if ((StringCi] >= *0') && (StringCi] <= '9')) 

< /* Ziffern V 

hex += (StringCi] - *0*)*faktor; 
faktor *= 0x10; 

> 


if (((StringCi] & MASK) >= *A*) && 

((StringCi] & MASK) <= »F*)) 

{ /* Hex-Ziffern */ 

hex += ((StringCi] & MASK)-*A*+0xa)*faktor; 
faktor *= 0x10; 

> 

> 


> 


return (hex); 
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main (arge, argv) 
int arge; 
ehar **argv; 
i 

int i; 

if (arge != 3) /* Anzahl der Parameter ist falseh */ 

C 

printf (»USAGE: mon ANFANG ENDE\n**); 
exit (10); 

> 

lowadress = atoh (argv[1]); /* Niedrigste und höehste */ 
highadress = atoh (argv[2]); /* Adresse ausreehnen */ 

if (lowadress > highadress) /* Fehler bei Eingabe */ 

C 

printf ("ANFANG muss kleiner als ENDE sein !!!\n"); 
exit (10); 

> 

for (i=0;i<32 ;i++) Conversion_Table[i] = 

for ( ;i<128;i++) Conversion_TableCi] = (ehar)i; 

for ( ;i<160;i++) Conversion_Table[i] = *.*; 

for ( ;i<256;i++) Conversion^TableCi] = (ehar)i; 

/* Conversion_Table aufbauen V 

pos = lowadress; /♦ aktuelle Position gleich V 

/* niedrigser Adresse */ 

while (pos < highadress) /* Ausgabeschleife */ 

if ((long) (highadress'pos) >= WIDTH) Show (WIDTH); 
eise Show ((long) (highadress-pos)); 


Show (ok) 
long ok; 

int i; 

printf ("$%08lx ‘^pos); /* Position ausgeben */ 

for (i=0;i<ok;i++) 

printf ("$%02x ",*(pos+i)); /* Byte als Hex ausgeben */ 

if (ok < WIDTH) for ( ;i<WIDTH;i++) 

printf (" **); /* Platz mit Leerstellen */ 

/* füllen V 

printf (" *'); 
for (i=0;i<ok;i*»'+) 

printf ("%c",Conversion_Table[*(pos-»-+)] ); 

/* Bytes als Hex */ 




Die Sprache C 


51 


printf("\n"); /* Carriage-Return ♦/ 

> 

Beachten sollten Sie, daß der Inhalt der angegebenen Endadresse 
nicht ausgegeben wird, mon 100 200 zeigt also die Inhalte der 
Speicherstellen Hex 100 bis einschließlich Hex Iff. 


1.5 Der Lattice-C-Compiler 4.0 

Neben dem Aztec-Compiler existiert noch ein weiterer guter C- 
Compiler: der Lattice-Compiler. Dieser Compiler war der erste 
C-Compiler, der für den Amiga zur Verfügung stand. Auf ihm 
wurden auch einige Betriebssystemroutinen entwickelt. 

Dieser Compiler wird auf 3 Disketten geliefert. Auf der ersten 
Diskette (Lattice_C_4.0.1) befinden sich der Compiler (Ic) und 
der Linker (blink). Auf der zweiten Diskette findet man die 
Linker-Librarys und C-Include-Files. Mit diesen Include-Files 
hat es allerdings eine besondere Bewandtnis: Sie sind kompri¬ 
miert. Dadurch ist es möglich, den Vorgang des Include-File- 
Compilierens zu beschleunigen. Diese Komprimierung bezieht 
sich allerdings nicht darauf, daß aus diesen Files alle Kommen¬ 
tare entfernt wurden wie beim Aztec-Compiler, sondern diese 
Files sind sozusagen vor-compiliert. Auf der zweiten Diskette 
findet man außerdem einige Source-Files (unter anderem den 
Startup-Code, die Routine, die Ctrl-C abfängt usw.). Die dritte 
Diskette des Lattice-Pakets schließlich enthält neben einigen 
Beispielprogrammen nochmals alle Include-Files, diesmal aber 
unkomprimiert. 

Doch kommen wir dazu, wie man den Lattice-Compiler instal¬ 
liert bzw. mit Hilfe einer Startup-Sequenz dafür sorgt, daß man 
compilieren kann. Dazu müssen zunächst vier Umgebungsvari¬ 
ablen mit Hilfe des ASSIGN-Befehls gesetzt werden: 

ASSIGN LC: Lattice_C_4.0.1 :c ;Wo ist der Cotnpiler? 

ASSIGN INCLUDE: Lattice_C_4.0.2:include ;Wo sind die Includes? 

ASSIGN LIB: Lattice_C_4.0T2:lib ;Wo sind Linker-Libs? 

ASSIGN OUAD: ram: ;Uohin mit temporären Files? 
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Wie Sie sehen, werden die ersten beiden Disketten zum Compi- 
lieren eines Files benötigt. Dies macht es fast unumgänglich, den 
Lattice-Comiler mit mindestens zwei Laufwerken oder einem 
Laufwerk und einer Harddisk zu betreiben (Lattice gibt als beste 
Konfiguration für den Betrieb vor: 2 Laufwerke, 1 Harddisk 
(mit mind. 20 MB), 2,5 MB Speicher). Natürlich läßt sich der 
Lattice-Compiler auch nur mit einem Laufwerk betreiben. Al¬ 
lerdings müssen dann sehr oft Diskettenwechsel durchgeführt 
werden. 

Wenn Sie die obigen Befehle in Ihre Startup-Sequenz eingefügt 
haben (neben der Installation des deutschen Tastaturtreibers 
usw.), kann es eigentlich schon losgehen. Leider stellt der Lattice 
kein Make-ähnliches Utility zur Verfügung, so daß der Benutzer 
mit Hilfe von Batch-Files Programme compilieren muß. 

Das Batch-File einfachster Art sieht so aus: 

.key file 
LC:lc -L <file> 

Dieses Batch-File sorgt dafür, daß das angegebene File compi- 
liert und direkt im Anschluß daran gelinkt wird, so daß ein 
lauffähiges Programm entsteht. 

Betrachten wir einmal ein Batch-File, das den Linker explizit 
aufruft: 

•key flle 
LC:lc <file> 

LINKrblink FROM LIBrc.o <file>.o TO <file> LIB LIBilc.lib 
lib:amiga.lib 

Betrachten wir einmal den Linker-Aufruf genauer: 

Zunächst wird festglegt, welche Objekt-Files zusammengelinkt 
werden sollen (FROM). In unserem Beispiel wird zunächst der 
Startup-Code, der ja zu Beginn eines jeden Programms stehen 
muß, angegeben. Darauf folgt das eigentliche Compilat 
(<file>.o). Das TO-Schlüsselwort bestimmt, welchen Namen das 
lauffähige Programm erhalten soll (<file>). Nun folgt das 
Schlüsselwort LIB (nicht zu verwechseln mit der Umgebungsva- 
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riable LIB:!). Die nach diesem Schlüsselwort folgenden Librarys 
werden zum Linken verwendet. Dabei enthält die Ic.lib alle Lat- 
tice-spezifischen Routinen (strlen(), fopen() usw.), während die 
amiga.lib alle Aufrufe der Amiga-Betriebssystemroutinen 
(WriteO, Move(), Draw() etc.) enthält. 

Mit Hilfe dieses Batch-Files ist es also möglich, ein Programm 
zu compilieren. (Wenn mehrere Module zusammengelinkt werden 
sollen, brauchen Sie die Namen der einzelnen Module nur nach 
dem FROM-Schlüsselwort aufzulisten, getrennt durch ein + oder 
Leerzeichen). 

Da wir, wie oben schon gesagt, im Buch auf den Aztec-Compi- 
1er eingehen, und dessen Optionen im Verlauf des Buches erläu¬ 
tern, finden Sie im Anhang eine Erklärung der Lattice-Compi- 
1er- und Linker-Optionen. 
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2. Der Compiler unter der Lupe 

Allen drei Versionen des C-Compilers gemeinsam ist der Com¬ 
piler, Assembler und Linker. Wir wollen uns nun mit dem Com¬ 
piler, dem Assembler und dem Linker und deren Optionen be¬ 
schäftigen und dem Compiler beim Compilieren ein wenig auf 
die Finger schauen. 

Dazu betrachten wir zunächst den Aufruf des Compilers. Er er¬ 
folgt nach dieser Form: 

cc [>AusgabeFile] [Optionen] ProgC.c] 

Dabei ist alles, was in eckigen Klammern steht, optional, muß 
also nicht unbedingt angegeben werden. Angegeben werden muß 
der Name des zu compilierenden Files. Dabei ist es dem Compi¬ 
ler egal, ob Sie statt "cc Programm" "cc Programm.c" angeben. 

Das Ausgabe-File und die Compiler-Optionen können Sie optio¬ 
nal angeben. Das Ausgabe-File ist besonders bei der Programm¬ 
entwicklung von Nutzen. Hier werden alle Texte, die der Com¬ 
piler ausgibt, hineingeschrieben - also auch die eventuellen 
Fehlermeldungen. Geben Sie z.B. cc >prt; Programm an, wird 
folgender Text auf dem Drucker ausgeben, wenn das Programm 
keine Fehler aufweist: 

"Aztec C68K 3.4a 1-25-87 (C) 1982-1987 by Manx Software 

Systems, Inc. 

Aztec 68000 Assembler 3.4a 1-25-87" 

Doch können Sie die Texte auch auf ein Disketten-File lenken - 
z.B. auf errors.c - und dieses ASCII-File dann in Ruhe mit dem 
Ed anschauen (cc >errors.c Programm). 

Die Möglichkeit der Umlenkung der Ausgabe der Texte auf ein 
anderes File nennt man "Re-Direction". Diese Möglichkeit läßt 
sich bei fast jedem CLI-Kommando anwenden, so auch bei As¬ 
sembler und Linker. Mit dir >prt: kann man z.B. das aktuelle 
Directory auf den Drucker ausgeben. 
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Bei der Ausgabe der Compiler-Texte auf den Drucker o.ä. soll¬ 
ten Sie beachten, daß der Benutzer nach jeweils fünf aufgetrete¬ 
nen Fehlern (nicht Warnings) aufgefordert wird, den Fortgang 
der Compilation zu bestätigen. Dies hat den Vorteil, daß die 
Fehlermeldungen, die ja normalerweise auf dem Bildschirm aus¬ 
gegeben werden, nicht so schnell an Ihnen vorbeihuschen. Sie 
haben die Möglichkeit, alle Fehler zu betrachten, obwohl es 
vielleicht so viele sind, daß nicht alle auf einmal auf den Bild¬ 
schirm passen. 

Bei der Ausgabe der Fehler auf einen Drucker oder ein File ist 
diese Bestätigung aber nicht notwendig, da die Texte ja "konser¬ 
viert" werden, so daß Sie den Zwang zur Bestätigung durch die 
Compiler-Option -B (Eselsbrücke: "minus Bestätigung") aufheben 
sollten. 

Im übrigen hat ein Fehler im C-Programm immer folgendes 
Format: 

Listing_der_Fehlerhaften_Zeile 

Prograiniiname.c:Fehlerhafte_Zeile: ERROR Nunnier: 

Kurzbeschreibung: 


Z.B: 


> 

test.c:23: ERROR 69: missing semicolon 


Das Potenz-Zeichen (^) gibt an, wo sich - nach Meinung des 
Compilers - der Fehler in der fehlerhaften Zeile befindet. Beim 
"missing semicolon"-Fehler, der die Nummer 69 hat, merkt der 
Compiler den Fehler immer erst einen Befehl später. Da es ein 
ungeschriebenes Gesetz ist - an das sich leider nicht alle Pro¬ 
grammierer halten -, daß in eine Zeile nur ein Befehl geschrie¬ 
ben wird (abgesehen von If-Anweisungen mit nur einem Befehl 
im Rumpf), tritt dieser Fehler immer eine Zeile später auf. 

Kommen wir aber nun zu den Compiler-Optionen, von denen es 
eine ganze Menge gibt: 
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Compiler-Optionen 

-A 

Der Assembler wird nicht automatisch vom Compiler gestartet 
(minus Assembler-Option). 

-DSymbol[=Wert ] 

Diese Option weist dem angegebenen Symbol den optional an¬ 
zugebenden Wert zu. -DName=Wert kommt einem #define Name 
Wert gleich, während -DName dafür sorgt, daß das Symbol den 
Wert 1 erhält (#define Name 1) (Define-Option). 

-IDirectory 

Die Include-Files werden aus dem hier angegebenen Directory 
gelesen. Wollen Sie, daß mehrere Unterverzeichnisse durchsucht 
werden sollen, können Sie die zu durchsuchenden Directorys 
durch ein ! trennen (-IDirl!Dir2!Dir3) - (Include-Option). 

-OFilename 

Das Objekt-File (oder der Assembler-Source - bei Verwendung 
der Option -A) wird in das angegebene File geschrieben (Out¬ 
put-Option). 

-5 

Die Ausgabe von Warnings wird unterdrückt (Silent-Option). 

-r 

Im vom Compiler erzeugten Assembler-Source werden die ein¬ 
zelnen C-Zeilen als Kommentar angegeben. Diese Option ist al¬ 
lerdings nur in Verbindung mit -A sinnvoll (Text-Option). 

-B 

Bei der Ausgabe von Fehlermeldungen auf einen Drucker o.ä. ist 
es sinnlos, daß nach der fünften ausgegebenen Fehlermeldung 
auf eine Bestätigung Ihrerseits zum Fortsetzen der Compilation 
gewartet wird. Die Fehlermeldungen gehen in diesem Falle ja 
nicht verloren, wie es bei der Ausgabe auf den Bildschirm ge¬ 
schehen würde, wenn noch mehr Fehlermeldungen ausgegeben 
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würden. Sie können nun mit dieser Option den Zwang zur Be¬ 
stätigung unterdrücken (minus Bestätigung-Option). 

-ENummer 

Diese Option veranlaßt den Compiler, eine Ausdruck-Tabelle 
mit Nummer Einträgen zu allokieren. Diese Ausdruck- bzw. Ex- 
pression-Table wird zur Auswertung von For-Schleifen, Switch- 
Case-Anweisungen etc. benötigt (Rekursion). 

-LNummer 

Diese Option veranlaßt den Compiler, Nummer Einträge für die 
lokale Symboltabelle zu reservieren. Diese lokale Symboltabelle 
wird für Variablendefinitionen und -deklarationen innerhalb von 
Prozeduren bzw. Blöcken ( von { und ) eingeschlossene Pro¬ 
grammsegmente - z.B. bei If, For, Switch etc.) verwendet. 

-YNummer 

Diese Option veranlaßt den Compiler, eine Case-Tabelle mit 
Nummer Einträgen anzulegen. Diese Case-Tabelle wird für die 
Übersetzung der Switch-Anweisungen benötigt. 

-Z Nummer 

Diese Option veranlaßt den Compiler, eine String-Tabelle mit 
Nummer Einträgen anzulegen. Die String-Tabelle wird zur 
Speicherung der Strings während der Compilation benutzt. 

+B 

Diese Option verhindert die Erzeugung von public.begin im As¬ 
sembler-File. Dies ist bei der Benutzung mehrerer Module 
wichtig, um zu verhindern, daß in jedem Modul der Befehl 
jmp.begin erzeugt wird, was eigentlich nur im ersten Modul ge¬ 
schehen muß. 

+C 

Es wird "large Code" erzeugt (siehe Kapitel 2.3). 

+D 

Es wird "large data" erzeugt. 
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+HFilename 

Mit dieser Option können Sie die vom Compiler für ein Pro¬ 
gramm erzeugte Symboltabelle abspeichern. 

+IFilename 

Mit dieser Option können Sie die vorher mit +H abgespeicherte 
Symboltabelle wieder laden. Sie können z.B. die von einem Pro¬ 
gramm verwendeten Include-Files compilieren, abspeichern und 
mittels +I einiesen. Dadurch wird ein Geschwindigkeitsvorteil 
erreicht, da die Include-Files nicht immer wieder neu compiliert 
werden müssen. 

+L 

Diese Option veranlaßt den Compiler, alle Int-Variablen als 
Long-Variablen zu interpretieren. Bei Verwendung der c32.1ib 
ist es nun möglich, Lattice-Programme zu übernehmen. 

+Q 

Die in einem Programm verwendeten Strings werden ins Daten¬ 
segment geschrieben. 

+ff 

Berechnungen werden mit einfacher Genauigkeit durchgeführt, 
m.lib muß zum Objekt-File des Programms gelinkt werden. 

+fi 

Berechnungen werden mit doppelter Genauigkeit durchgeführt. 
Sie müssen bei Verwendung der "double-precision floating-point 
routines" die ma.lib oder die mx.lib beim Linken verwenden. 

+f8 

Es wird der 68881-Mathe-Coprozessor für die Berechnungen 
verwendet. Zur Benutzung dieses Prozessors, der nachträglich 
eingebaut werden kann, müssen Sie zum Programm die m8.1ib 
linken. 
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+m 

Vor Eintritt in jede Routine wird geprüft, ob ein Stack-Over¬ 
flow (Stack-Überlauf) aufgetreten ist. Wenn ja, meldet sich der 
Compiler mit einer dahingehenden Fehlermeldung. 

-n 

Es werden Debugging-Informationen in der Assembler-Source 
eingebettet, die vom Assembler weiterbearbeitet werden. 

+P 

Diese Option ist identisch mit den Optionen +C +D +L. Weiter¬ 
hin werden die Register D2 und D3 vor jedem Funktionsaufruf 
gerettet. Diese Option verlangt, daß die cl32.1ib zum Programm 
gelinkt wird. 

Einige dieser Optionen erklären sich von selbst. So z.B. die Op¬ 
tion -a, die man sich vielleicht durch die Eselsbrücke "minus 
Assembler" merken könnte. Sie veranlaßt den Compiler nämlich, 
den Assembler nicht zu starten, wie er es sonst tut. 

Damit der Compiler aber nicht umsonst compiliert, müssen Sie 
angeben, wohin das Assembler-Source-File, das der Compiler 
normalerweise in der RAM-Disk erzeugt (siehe CCTEMP-Va- 
riable) und nach Gebrauch wieder löscht, geschrieben werden 
soll. Dazu müssen Sie den Namen des Assembler-Source-Files 
mittels der -0(Output)-Option angeben. Der separate Aufruf 
von Compiler und Assembler, den Sie ja nun selber aufrufen 
müssen, verlängert sich damit schon auf: 

cc -A -0 Programm.asm Programm.c 
as Programm.asm 

Nicht nur, daß mehr Parameter an cc übergeben werden müssen 
- nein. Sie müssen auch den Assembler "von Hand" aufrufen, 
der aus Programm.asm das Objekt-File Programm.o erzeugt. (Es 
hat sich eingebürgert, daß Assembler-Source-Files die Extension 
.asm erhalten, ebenso wie beim C-Source das Tag .c an den 
File-Namen angehängt wird. Objekt-Files hingegen erhalten das 
Tag .o) Geben Sie beim Compilieren nur die Option -O an (ohne 
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-A), so erhält das Objekt-File, das der vom Compiler aufgeru- 
fene Assembler erzeugt, den angegebenen Namen. 

Normalerweise brauchen Sie den Namen für das Objekt-File 
aber nicht anzugeben, da automatisch ein Objekt-File mit dem 
Namensstamm des Programm-Files, aber auf .0 geänderter Ex¬ 
tension, erzeugt wird. Ein kleiner Tip am Rande; Sollte Ihr Pro¬ 
gramm einmal so groß sein, daß Sie um jedes Byte Speicherplatz 
auf der Diskette kämpfen müssen, so sollten Sie das Objekt-File 
nach jedem Link-Vorgang mit "delete" wieder löschen. Dies 
kann sowohl bei der Professional-Version im Batch-File als auch 
bei der Developers-Version im Make-File geschehen. Dies ist 
allerdings nur dann interessant, wenn Sie mehrere Programme, 
die jeweils nur aus einem Modul bestehen, auf einer Diskette 
haben. 


2.1 Dem Compiler auf die Finger geschaut 

Um die weiteren Compiler-Optionen zu erläutern, wollen wir 
uns den Compiler ein wenig genauer ansehen. Wir wollen beob¬ 
achten, wie der Compiler mit einem Programm, das als ASCII- 
File vorliegt, umgeht. 

Zunächst untersucht der Compiler das Programm nach offen¬ 
sichtlichen Fehlern. Der Compiler weiß z.B., daß nach jedem 
Befehl ein Semikolon folgen muß. Findet der Compiler das Se¬ 
mikolon nach einem Befehl nicht, quittiert er das mit einer 
Fehlermeldung. Wenn nach einer If-Anweisung die zu testende 
Bedingung fehlt, wird das festgestellt und dem Programmierer 
unmißverständlich mitgeteilt. Es gibt aber auch Fehler, die der 
Compiler nicht erkennen kann und die nur Sie als Programmie¬ 
rer feststellen können - meist dann, wenn Ihr Programm abstürzt 
oder nicht das tut, was Sie von ihm verlangen. Dann tritt der 
Debugger in Aktion (siehe Kapitel 2.5). 

Ein typischer Fehler dieser Art ist z.B. die Verwechslung von == 
und = bzw. ein vergessenes Gleichheitszeichen (=) bei der Be¬ 
dingung einer If-Anweisung (z.B. if (a=l) {..)). Der Rumpf der 
If-Anweisung wird nie ausgeführt, und der Programmierer wun- 
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dert sich, warum. Wenn sich der Benutzer allerdings nicht da¬ 
rüber wundert, daß der If-Rumpf'nicht ausgeführt wird, weil er 
es gar nicht erwartet, so wundert er sich darüber, daß die Va¬ 
riable a auf einmal den Wert 0 hat. 

Beliebt ist aber auch der Zugriff auf ein nicht existentes Array- 
Element: 

int Array[4]; 

Dieses Array enthält die Elemente 0, 1, 2 und 3, also insgesamt 
4 Elemente. Weisen Sie nun aber an Array[4], das "fünfte" Ele¬ 
ment, einen Wert zu, kann es passieren, daß Sie eine andere, für 
das Programm sehr wichtige Variable ändern und so den Pro¬ 
grammabsturz "vorprogrammieren". Da, wie Sie gleich noch er¬ 
fahren werden, Arrays auch auf dem System-Stack abgespeichert 
werden, könnte es auch passieren, daß Sie bei einem Array-Zu- 
griff die Rücksprungadresse einer Subroutine zerstören, was 
verheerende Folgen hat. 

Bei solchen Fehlern hilft Ihnen meist nur noch ein gutes Auge 
und ein Gespür dafür, wo solche Fehler verborgen sein könnten 
- oder der Debugger (dieser war es, der uns einen solchen feh¬ 
lerhaften Array-Zugriff aufdeckte). 

Doch nach dem Test auf Fehler folgt die Übersetzung der Be¬ 
fehle und Anweisungen in Maschinensprache. Diese Übersetzung 
kann direkt nach der Fehlerüberprüfung eines Befehls geschehen 
oder nachdem der Compiler das ganze Programm nach Fehlern 
durchsucht hat und festgestellt wurde, daß keine Fehler mehr 
enthalten sind. 


2.1.1 Interne Organisation der Variablen und Strukturen 

Wurde sichergestellt, daß in dem zu compilierenden Programm 
keine Syntax-Fehler usw. enthalten sind, kann mit der Überset¬ 
zung des Programms begonnen werden. Meist besteht ein C-Pro- 
gramm aber nicht nur aus Befehlen, sondern auch aus Vari- 
ablen-Definitionen und -Deklarationen. 
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Bevor wir uns den eigentlichen C-Befehlen widmen, betrachten 
wir deshalb, wie Variablen und Strukturen "übersetzt" werden: 

Erst einmal muß festgestellt werden, welchen Typs die einzelnen 
Variablen sind. Die Sprache C kennt folgende "skalare" Typen: 

int, long char, short, unsigned char, unsigned int, 
unsigned long, float, double und den Zeiger. 

Zusammengesetzte Typen sind das Array (oder der Vektor), die 
Struktur, der Aufzählungstyp, die Bitfelder und die Union. 

Der Compiler codiert jeden dieser Typen und speichert den Va¬ 
riablennamen und dessen Typ-Code in der sogenannten (glo¬ 
balen) Symboltabelle ab. Wir wollen an dieser Stelle darauf hin- 
weisen, daß die folgenden Symboltabellen die eines Modell-C- 
Compilers und nicht die des Aztec-Compilers sind. Dennoch ar¬ 
beitet der Aztec-Compiler grundsätzlich nach dem gleichen 
Prinzip beim Compilieren wie unser Modell-Compiler. 

int Wert; 
char Value; 

Symboltabelle: 

" We r t" / CcKle_f ü r_ I n t / E nd_Code/•'Va l ue''/Code_f ü r_Ch a r / E nd_Code 

Bei Strukturen sieht dies ähnlich aus. Auch hier folgt zuerst der 
Name der Struktur, auf den ein Code (ein einzelnes Byte) für 
den Beginn der Struktur folgt. Dann werden alle in der Struktur 
enthaltenen Variablen aufgelistet: 

struct Nonsense 
C 

int hallo; 
char na; 

unsigned char wie_gehts; 

>; 

Symboltabelle: 

•'Nonsense'7Code_für_Struktur_typ/'*hallo"/Code_für_Int/ 

**na''/Code_für_char/*'wie_gehts**/Code_für_unsigned_char/End_Code 

Dies ist eine Struktur-Deklaration. Die einzelnen Codes haben 
wir hier durch Texte angedeutet (z.B. Code_für_char anstatt ei- 
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nes nichtssagenden Byte wertes (z.B. 0x21)). Mit ihr wird ein 
Struktur-Typ festgelegt. Erst nach einer Struktur-Definition 
(struct Nonsense Nonsense_Struktur) kann mit der Struktur ge¬ 
arbeitet werden. Sie haben also sozusagen einen Struktur-Typ 
geschaffen. Dies ist ja auch mittels typedef möglich (typedef 
struct (...) Struktur_Typ_Name). Mit typedef lassen sich aber 
auch bekannte Typen zu anderen zusammenfassen: 

"typedef unsigned char BYTE" 

Symboltabelle: 


"BYTE"/CcxJe_f ür__typ__beg i nn/ 

C ode__f ü r_uns i g ned/ Code_f ür_ch a r/ E nd_C ode 

Das Include-File exec/types.h enthält eine Menge solcher neuer 
Typen, die von fast allen anderen Include-Files benutzt werden. 
Sie sind also unabdingbar für die Benutzung von Include-Files 
und müssen immer vor Verwendung anderer Include-Files ein¬ 
gebunden werden. 

Doch zurück zu den Strukturen. Die Symboltabelle zu einer 
Struktur-Definition sieht wie folgt aus: 

Struct Nonsense Nonsense_Struktur; 

Symboltabelle: 


"Nonsense_S t rukur"/Code_f ür_St rukturlDeg i nn/ 
"Nonsense'7Code_für__Struktur_typ/End_Code 

Man kann die Nonsense_Struktur direkt definieren. Die Struktur 
steht dann nicht mehr für weitere Definitionen zur Verfügung: 

struct 

int hallo; 
char na; 

unsigned char wiergehts; 

> Nonsense_Struktur; 

Symboltabelle: 


"Nonsense_Struktur"/Code_für_Strukturbeginn/"hallo"/Code_für_Int/ 
"na"/Code_für_char/"wie_gehts"/Code__für_unsigned_char/End_Code 
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Eine Definition der Form struct Nonsense_Struktur Name ist 
hier nicht mehr erlaubt. Bei der Deklaration von Bitfeld, Array, 
Aufzählungstyp und Union sieht es ähnlich wie bei der Struktur 
aus: 


ARRAY: 

1 nt Augenzahl[6]; 

Symboltabelle: 

"Augenzahl"/Code_für_Array/Code_für_Int/6/End_Code 
AUFZÄHLUNGSTYP: 

enum färbe = rrot, gruen, blau>; 

Symboltabelle: 

"farbe"/Code_für_Enum/"rot"/0/"gruen"/1/"blau"/2/End_Code 

Interessant beim Aufzählungstyp ist, daß die einzelnen Aufzäh¬ 
lungstypen (rot, gruen, blau) im Programm durch Integer-Zahlen 
repräsentiert werden, färbe = 0 würde also dasselbe bedeuten 
wie färbe = rot. 

Der Aufzählungstyp kann mit einer Flut von #define-Anwei- 
sungen verglichen werden. Statt enum färbe = {’rof, ’gruen’, 
’blau’}; könnte man schreiben: 

#define rot 0 
#define gruen 1 
#define blau 2 

int färbe; 

Bei den Define-Anweisungen sollte man beachten, daß ihre 
Symboltabellen nur aus Strings bestehen, die an der Stelle, in 
denen ein mit #define definiertes Symbol auf tritt, eingesetzt 
werden und so ohne große Probleme compiliert werden können. 

Syinboltabelle für Defines: 

'•rot'VCode für Def ine/"0"/End_Code/"gruen"/Code_für Define/ 
/"1"/End_CÖde/"blau"/Cocte_für_Define/"2"/End_Code 








66 


Das große C-Buch zum Amiga 


Insbesondere bei mathematischen Ausdrücken, die mit Define- 
Anweisungen definiert werden, ist Vorsicht geboten: 

#def 1 ne Summe a+b 


pn'ntf ("%d %d",Summe,Summe*10); 

Der printf-Befehl gibt zunächst die Summe der beiden Variablen 
a+b aus. Sollte die zweite Ausgabe das Zehnfache der Summe 
darstellen, werden Sie hier wahrscheinlich enttäuscht. Der Com¬ 
piler generiert aus Summe* 10 nämlich a+b* 10. Er addiert zum 
Wert von a den zehnfachen Wert von b. Um dies zu vermeiden, 
sollten Sie die Summe klammern: 

#define Summe (a+b) 


Im Zusammenhang mit der Define-Anweisung sind die #ifdef-, 
#ifndef- und #endif-Direktiven zu nennen. Diese treten sehr 
häufig in den Include-Files auf und dienen meist dazu, schon 
compilierte Include-Files nicht ein zweites oder drittes Mal zu 
compilieren, da dies zu Fehlern führen würde (redefinierte Sym¬ 
bole etc.). Da die meisten Include-Files auf anderen Include-Fi¬ 
les aufbauen, werden innerhalb eines Include-Files meistens 
weitere Includes getätigt: 

/* **** Include-File **** */ 

#ifndef EXEC_TYPES_H 

#include "exec/types.h" 

#endif 

#ifndef GFX^H 
#include "graphics/gfx.h” 

#endif 


/* Wenn EXEC__TYPES_H nicht */ 
/* definiert, V 
/* dann include exec/types.h */ 


/* Wenn GFX__H nicht definiert, */ 
/* dann include graphics/gfx.h */ 


Anhand der Symboltabelle kann der Compiler sehr einfach fest¬ 
stellen, ob ein Symbol definiert (#ifdef) oder nicht definiert 
(#ifndef) ist, und kann dann - je nachdem ob #ifdef oder 
#ifndef verlangt wurde - über das Schicksal der im #if...-endif- 
Block eingeschlossenen Statements entscheiden. Jedes Include- 
File definiert zu Beginn ein Symbol mit dem Namen Include- 
File H. 
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Wenden wir uns nun den Bitfeldern zu. Diese sind ein neues 
Feature, das der Aztec erst seit der neuesten Version (3.4a) 
kennt. Da Bitfelder ziemlich unbekannt sind, wollen wir ihre 
Benutzung hier erläutern: 

Wie der Name Bitfeld schon sagt, handelt es sich bei Bitfeldern 
um Datenorganisationen, die mit einzelnen Bits arbeiten. Dekla¬ 
riert werden sie ähnlich wie Strukturen: 

struct Bitfeld 
< 

unsigned 2:; 
unsigned 1: a; 
unsigned 1: b; 
unsigned 1: c; 
unsigned 3:; 

struct Bitfeld bf; 

Diese Deklaration erzeugt ein 8 Bit breites Bitfeld. Sie können 
nun auf Bit 2, 3 und 4 mittels bf.a, bf.b und bf.c zugreifen. Da¬ 
bei können Sie an diese Variablen nur die Werte 0 und 1 zu¬ 
weisen. Das ist ja auch nur logisch, da ein Bit nur die beiden 
Zustände 0 (aus/nein) und 1 (an/ja) kennt. 

Auf die Bits 0, 1, 5, 6 und 7 können Sie nicht zugreifen, da 
diesen keine Namen gegeben wurden. Diese Bits wurden durch 
die Anweisungen unsigned 2:; beziehungsweise unsigned 3:; 
"übersprungen". 

Die Symboltabelle zu obiger Bitfeld-Deklaration und -Definition 
sieht wie folgt aus: 

Symboltabelle: 


/* Bit 0 und 1 */ 
/* Bit 2 •/ 

/* Bit 3 */ 

/* Bit 4 V 


"Bitfeld'VCode für typ Beginn/""/Code für_BitO/""/Code für Biti/ 
"a"/Code_Bit2/"b"/Code“für_Bit3/"c"/CÖde_für_Bit4/""/ “ 

Code_Bit5/""/Code_für_Bit6/""/Code_für_Bit7/End_Code 


Definition: 

"bf"/Code_für_Strukturbeginn/Code_für_typ/"Bitfeld"/End_Code 
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Wenden wir uns nun aber dem letzten nicht skalaren Datentyp 
zu - der Union. 

Sie bezeichnet eine Variable, die mehr als einem Datentyp ange¬ 
hören kann: 

Union zahl 
i 

int i; 
float f; 

>; 


Union zahl z; 
Symboltabelle: 


"Zah l "/Code_f ür_Uni on_typ/" i '7Code_f ür_i nt/''f "/ 
Code_für_float/End_Code 

Definition: 


"z“/Code_für_Union_typ/"zahl"/End_Code; 

Die Variablen i und f belegen denselben Speicherplatz und kön¬ 
nen somit einmal in der einen, einmal in der anderen Art und 
Weise interpretiert werden. 

Betrachten wir nun Zeiger auf die einzelnen Variablen, Struk¬ 
turen und Arrays, so muß nur der Code für den Zeiger einge¬ 
führt werden; 

int *Zeiger; 

struct Nonsense ‘Sensible; 

Symboltabelle: 


"Zeiger"/Code_für_Zeiger/"Sensible"/Code_für_lnt/EndCode/ 

"Sensible“/ 

Code_für_Zeiger/"Nonsense"/Code_für_Struktur_typ/EndCode 

Die so auf gebaute Symboltabelle wird beim Übersetzungsvorgang 
immer dann benötigt, wenn mit einer Variablen gearbeitet wer¬ 
den soll. Will man z.B. die Variable i inkrementieren (i++), so 
muß der Compiler wissen, welchen Typs diese Variable ist. 
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Angenommen, i sei ein Int-Objekt, so weiß der Compiler, daß 
diese Variable 16 Bit breit ist und er nicht add.l 
#l,Adresse_von_i oder add.b #l,Adresse_von_i, sondern 
add.w #l,Adresse_von_i für den Assembler-Source generieren 
muß. Damit der Compiler den Symbol-Eintrag für eine Variable 
schnell findet, werden immer zuerst die Namen der Variablen 
und dann die Typen abgespeichert. 

Ähnlich ist es mit der Zuweisung von Werten an Struktur-Ele¬ 
mente, Z.B.: Sensible->hallo = 0. Zunächst muß der Compiler 
herausfinden, ob "Sensible" überhaupt ein Zeiger ist. Aus der 
Symboltabelle erfährt er: "Sensible"/Code_für_Zeiger und weiß, 
daß Sensible ein Zeiger ist. Nun muß er erfahren, auf was für 
ein Objekt Sensible zeigt. Zeigt Sensible nämlich auf eine Int- 
Variable, so ist die Zeile Sensible->hallo sinnlos, da Int-Vari- 
ablen keine weiteren Elemente, wie die Strukturen, enthalten. 

Aus der Symboltabelle erfährt der Compiler aber, daß Sensible 
auf eine Struktur zeigt. Der ->-Operator ist also auch erlaubt. 
Sensible->hallo kann übrigens auch durch (^Sensible).hallo er¬ 
setzt werden, wobei zu beachten ist, daß der Punkt (.) eine hö¬ 
here Priorität als der Stern (*) vor Sensible hat, weswegen die 
Klammerung notwendig ist. 

Würden Sie Sensible.hallo programmieren, so würde der Com¬ 
piler das mit einer Fehlermeldung quittieren (falsche Pointer- 
Benutzung). 

Nun muß der Compiler nur noch überprüfen, ob die Struktur, 
auf die Sensible zeigt, überhaupt ein Element namens "hallo" 
enthält. Auch dies erfährt er aus der Symboltabelle. Zunächst 
zeigt "Sensible" auf ein "Nonsense"-Objekt, und in der Symbolta¬ 
belle für Nonsense läßt sich das Element hallo ausmachen. Nun 
braucht der Compiler nur noch zu überprüfen, ob die Zu¬ 
weisung von 0 an die Variable hallo der Nonsense-Struktur er¬ 
laubt ist, und wenn ja, muß er bestimmen, wie diese Zuweisung 
aussehen soll. Nachdem der Compiler aus der Symboltabelle für 
Nonsense erfahren hat, daß hallo ein Int-Objekt ist, kann er 
clr.w Adresse_von_Sensible->hallo angeben. 
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Der Compiler überprüft während des Compilier-Vorgangs bei 
jedem Zugriff auf eine Variable, welchen Typs diese Variable 
ist. Wollen Sie z.B. eine Variable an eine andere Variable unter¬ 
schiedlichen Typs zuweisen, generiert der Compiler beim Com- 
pilieren ein Warning, das Sie darauf hinweist, daß eine illegale 
Typzuweisung durchgeführt wurde. 

Bei normalen Variablen wie int, char und long nimmt der Com¬ 
piler Typzuweisungen untereinander ohne Cast nicht übel. Dies 
liegt daran, daß bei der Zuweisung von z.B. einem Int-Objekt 
an ein Char-Objekt nur die unteren acht Bits der Int-Variablen 
an die Char-Variablen übergeben werden bzw. die fehlenden 
Bits bei einer Zuweisung von char nach long mit Nullen auf¬ 
gefüllt werden und eventuell eine Vorzeichenerweiterung ext.w 
bzw. ext.l durchgeführt wird. 

Problematisch wird diese Typkonvertierung aber im Zusammen¬ 
hang mit Zeigern: 

int ‘Eingabe; 

char ‘String = 'Der Amiga ist spitze !!!'; 

String = Eingabe; 

Der Compiler ist nicht sicher, ob sich der Programmierer im 
klaren darüber ist, daß er zwei Zeiger mit unterschiedlichen Ty¬ 
pen einander zuweist. Deshalb gibt der Compiler bei diesem 
Befehl ein Warning aus, das den Benutzer auf eine evtl, "falsche" 
Zeigerzuweisung hinweist. 

Es kann aber durchaus gewünscht sein, daß solch eine Zuwei¬ 
sung eines Int-Zeigers an einen Char-Zeiger geschieht, weil man 
vielleicht auf das höherwertige Byte der Int-Variablen, auf die 
der Int-Zeiger zeigt, zugreifen will. Durch einen Char-Zeiger ist 
das möglich, da Char-Objekte nur ein Byte breit sind und nach 
String-H- der Zeiger String auf die nächste Byte-Adresse zeigt. 

Will rviur! als Programmierer, daß diese Zuweisung geschieht, 
sollte man den Compiler mit Hilfe eines Casts davon in Kenntnis 
setzen: 


String = (char ‘)Eingabe; 
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Das obige Programmsegment weist neben dem Cast noch zwei 
weitere Besonderheiten auf: Erstens wird eine Variable bei der 
Definition initialisiert, und zweitens werden Strings verwendet. 

Bei der automatischen Initialisierung kommt zum Tragen, wo die 
Variable definiert wurde. Wurde die Variable nämlich außerhalb 
einer Funktion definiert, so wird der Speicherplatz, den diese 
Variable belegt, mittels dc.<b/w/l> Wert festgelegt: 


C: 


char *String = "Der Amiga ist spitze !!!"; 


Maschinensprache: 


dseg 
ds 0 

public _String 
String: 
dc.l .1+0 
cseg 

1 dc.b 68,101,114,32,65,77,73 
dc.b 112,105,116,122,101,32,33 
ds 0 

public _main 
ma i n: 


;Datensegment 
;0 Bytes reservieren 
;globle Variable 
;Spei eher mit Adresse 
;des Strings belegen 
; Ccxiesegment 

71,65,32,105,115,116,32,115 
33,33,0 ;ASCII-Codes 
;Null-Byte 


;ab hier gehts los 


Bei Initialisierungen innerhalb einer Funktion sieht das etwas 
anders aus: 


C: 


proc() 

C 

char *String = "Der Amiga ist spitze !!!" 

> 


Maschinensprache: 

;Prozedur ist global 
;Stack-Speicher belegen 


public _proc 
proc: 

link a5,#.2 
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movem.l .8,-(sp) 
lea .1,a0 
move.l a0,-4(a5) 

movem.l (sp)+,.8 
unlk a5 
rts 

.2 equ -4 
.3 reg 

.1 dc.b 68,101,114,32,65,77,73,71,65,32,105,115,116,32,115 
dc.b 112,105,116,122,101,32,33,33,33,0 
ds 0 ;Null-Byte 

Wie Sie sehen, nehmen die Strings eine ungewohnte Form an. Sie 
können nun nicht mehr die einzelnen Buchstaben erkennen, son¬ 
dern nur noch ihren ASCII-Code, in den sie vom Compiler 
Zeichen für Zeichen umgerechnet und "abgespeichert" werden. 
(Zu den häufig auftauchenden Assembler-Direktiven global, pu¬ 
blic, desg und cseg lesen Sie bitte das Kapitel 2.2.) 

An dieser Stelle ist es vielleicht angebracht. Sie auf die Breite 
der einzelnen Variablen hinzuweisen; 

Char-Objekte sind immer ein Byte breit und haben somit einen 
Wertebereich von -128 bis 127 oder 0-255, wenn man "unsigned 
char"-Variablen verwendet. Int-Variablen hingegen belegen 
schon zwei Bytes mit einem Wertebereich von -32768 bis 32767 
bzw. 0-65535. Long-Objekte sind 4 Bytes breit mit einem Wer¬ 
tebereich von -268435458 bis 268435457 bzw. 0-4294967295. 
Float-Variablen enthalten 4 Byte und Double-Variablen 8 Byte. 

Zeiger sind Variablen, die die Anfangsadresse einer Variablen 
oder Struktur enthalten. Aufgrund der Tatsache, daß der 68000er 
theoretisch 4 Gigabytes (ca. 4 Milliarden Bytes) adressieren 
kann, müssen Zeiger einen Wertebereich von 0 bis 4294967295 
haben. Dies wird dadurch erreicht, daß Zeiger immer 4 Bytes 
belegen, egal welchen Typs sie sind. Wie ein Adreßregister, mit 
dem ja auch auf jede Speicherstelle zugegriffen werden kann, 
enthalten die Zeiger immer 4 Bytes. 

Wenn Sie einen Zeiger auf ein Long-Objekt de- oder inkremen- 
tiereren wollen, sollten Sie beachten, daß zur alten Adresse vier 
Bytes hinzugezählt bzw. abgezogen werden. Der Zeiger zeigt 


;Register retten 
;Adresse des Strings -> aO 
;a0 -> Variable _String 
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dann also auf das nächste Long-Objekt. Ebenso ist es mit 
Strukturen. Angenommen, eine Struktur enthält 95 Bytes. Inkre- 
mentieren Sie den Zeiger mittels <Zeiger>-H- oder <Zei- 
ger>=<Zeiger>+l, so wird die Adresse um 95 Bytes erhöht. 

Wir sind jedoch die ganze Zeit davon ausgegangen, daß unser 
Programm bei der Variablendeklaration und -definition nur Va¬ 
riablen enthält, die außerhalb von Funktionen definiert bzw. de¬ 
klariert wurden. Nun kann man aber auch Variablen innerhalb 
einer Prozedur definieren, die nur für diese Prozedur bekannt 
sind. Dazu folgendes Programm: 

int i; 
main () 
prroc() 

int i; 

i = 

> 

Wie Sie sehen, taucht die Variable i zweimal auf. Wird in der 
Prozedur Proc in irgendeiner Programmzeile auf i zugegriffen, 
so weiß der Compiler, daß das eigens in dieser Routine de¬ 
finierte i gemeint ist. Um dies zu wissen, benötigt er aber eine 
zweite Symboltabelle. Würde der Compiler den Symbol-Code für 
die Variable i auch in die globale Symboltabelle schreiben, so 
hätte er keine Möglichkeit, zwischen dem globalen i, das vor 
main() definiert wurde, und dem i in proc() zu unterscheiden. 
Welches von beiden sollte er verwenden? 

Die zweite - lokale - Symboltabelle wird deshalb immer dann 
benutzt, wenn innerhalb einer Funktion Variablen deklariert und 
benutzt werden. Ist die Funktion aber übersetzt, so steht der 
gesamte Speicherplatz der lokalen Symboltabelle der nächsten 
Funktion zur Verfügung. Wird mit einem Befehl der Routine 
auf eine Variable zugegriffen, wird zunächst die lokale Symbol¬ 
tabelle durchsucht. Konnte die Variable dort nicht gefunden 
werden, so durchsucht der Compiler zusätzlich die globale Sym¬ 
boltabelle. Besonders im Zusammenhang mit der Benutzung der 
Librarys ist die Definition der Library-Base-Pointer innerhalb 
oder außerhalb einer Funktion besonders wichtig. Definieren Sie 
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z.B. den Zeiger auf die Intuition-Library (struct IntuitionBase 
*IntuitionBase) innerhalb einer Funktion (z.B. in main()), so 
können Sie die Funktionen von Intuition nicht benutzen. 

Diese benötigen die Variable _IntuitionBase, die aber nur durch 
die Assembler-Direktive global _IntuitionBase,4 für andere Mo- 
dule und Linker-Librarys zugänglich gemacht werden kann. 
Wird IntuitionBase innerhalb einer Prozedur definiert, so wird 
nur Stack-Speicher für diesen Zeiger belegt, auf den nicht mit 
dem Label _IntuitionBase zugegriffen werden kann. 

Aber zurück zur lokalen Symboltabelle. Natürlich benötigt auch 
sie Speicherplätze. Diese werden ohne Angabe Ihrerseits vom 
Compiler auf 1040 Bytes festgelegt. Doch meldet sich der Com¬ 
piler einmal mit der Fehlermeldung: "Local table full (Use -L)", 
so sollten Sie dem Rat des Compilers folgen und mit der Option 
-L den Speicher für die lokale Symboltabelle erhöhen. Dabei 
sollten Sie beachten, daß ein Eintrag 26 Bytes groß ist. Mit -L40 
werden 1040 Bytes reserviert. 1040 Bytes werden vom Compiler 
auch ohne Angabe der Option -L reserviert. 

Die globale Symboltabelle kann übrigens auch abgespeichert 
werden - die lokale nicht. Dies ist besonders dann von Nutzen, 
wenn Sie Programme schreiben, die sehr viele Include-Files ent¬ 
halten. 

Den Include-File-Block, der nur die Include-Anweisungen ent¬ 
hält, können Sie separat compilieren und die so unter Verwen¬ 
dung der Option +H erzeugte Symboltabelle abspeichern (cc 
+HCompiled_Includes Include_Block.h), wobei der Inlude-Block 
z.B. so aussieht: 

#include "exec/types.h” 

#include "graphics/gfx.h“ 

#include "graphics/geIs.h“ 

Danach können Sie dann diese Symboltabelle, die auf Diskette 
im File "Compiled_Includes" vorhanden ist, mit der Option +I 
wieder einiesen (cc +ICompiled_Includes Programm.c). Sie spa¬ 
ren so erstens die Zeit zum Einlesen der einzelnen Include-Files 
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und zweitens die Zeit, die für den Aufbau Ihrer Symboltabelle 
in diesem Fall benötigt wird. 


2.1.2 Software-Organisation der Variablen und Strukturen 

Die Inhalte der Variablen und Strukturen müssen in Speicher¬ 
stellen festgehalten werden. Den dazu benötigten Speicherplatz 
fordern die Prozeduren vom System-Stack an, wenn keine an¬ 
deren Speicherklassen (extern, static, auto, register) für die Va¬ 
riablen definiert wurden. Dazu wird vom Compiler mit Hilfe der 
Symboltabelle zunächst die Anzahl der Bytes berechnet, die den 
einzelnen Prozeduren für Variablen zur Verfügung gestellt wer¬ 
den müssen. 

Da der Compiler aus globaler und lokaler Symboltabelle weiß, 
welche Variablen verwendet werden, und er außerdem genau 
über die Breite der einzelnen Variablen unterrichtet ist, ist diese 
Berechnung für ihn ein Kinderspiel. Auch bei der Verwendung 
der sizeof()-Anweisung, mit der man die Anzahl der Bytes er¬ 
hält, die eine Struktur oder Variable belegt, greift der Compiler 
sehr intensiv auf die Symboltabelle - in ähnlicher Weise wie bei 
der Variablenspeicher-Zuweisung - zurück. 

Es kann aber zu ernsthaften Problemen kommen, wenn die Va¬ 
riablen mehr Speicherplatz benötigen als, der Stack zur Verfü¬ 
gung stellt. Doch Sie können mit der +m-Option das sogenannte 
Stack-Checking einschalten. Vor jedem Einsprung in eine Rou¬ 
tine wird die Routine ^stkchk#() aufgerufen, die bei einem 
Stack-Overflow (Stack-Überlauf) die Routine _stkover() an¬ 
springt. Bei einem Stack-Overflow verursacht _stkover() sofort 

einen Programmabbruch, und manchmal wird - zur Freude des 
Programmierers - auch ein Reset-Requester (Finish all disk acti- 
vities, ...) angezeigt. 

Im Handbuch zum Aztec steht geschrieben, daß _stkover() den 
Benutzer freundlich auf den Stack-Overflow hinweist (mit der 
Nachricht "Stack overflowü"), aber leider funktioniert das nicht 
immer reibungslos. Manchmal tritt der Guru in Aktion. Aber Sie 
können eine eigene _stkover()-Routine schreiben. Allerdings 
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sollte diese Routine in Maschinenspache geschrieben werden, 
denn in dieser können Sie einen Alternativ-Stack benutzen, wo¬ 
bei zu beachten ist, daß das Adreßregister a7, das ja zugleich 
der Stackpointer ist, auf die höchste Adresse des Alternativ- 
Stack-Speicherbereichs zeigt, da ein Stack nach unten "wächst". 

Beim Linken dieser neuen _stkover()-Routine sollten Sie wei¬ 
terhin beachten, daß eine Routine gleichen Namens schon in der 
c.lib enthalten ist. Der Linker hat also zwei Maschinensprache- 

Routinen mit dem Namen _stkover: zur Verfügung - erstens 

Ihre und zweitens die aus der c.lib (Dem Namen der C-Prozedur 
wird in Maschinensprache ein Unterstreicher vorangestellt!). Der 
Linker ist aber normalerweise (ohne Benutzung einer Linker- 
Option) so fair, Ihrer Routine den Vortritt zu lassen, da diese 
für den Linker eher als die der c.lib auftaucht. 

Sie sollten die Stack-Überprüfung sowieso nur in der Entwick¬ 
lungsphase benutzen. Die Programme werden durch den immer 
wiederkehrenden Aufruf von _stkchk#() beim Eintritt in jede 
Funktion oder Routine immer langsamer und größer. 

Doch kommen wir nun dazu, wie sich die Anlage von Variablen 
im Assembler-Source tatsächlich niederschlägt. Dazu folgendes 
kleine C-Programm: 

int c; 
mainO 

int j; 
j = 0; 

• • • » 

> 

proc() 

C 

int i; 
c = 0; 

• • • f 

> 

Der Einfachheit halber verwenden wir hier Int-Variablen. Doch 
im Prinzip funktioniert die Allokation bzw. Reservierung des 
Speicherplatzes für Strukturen, Arrays etc. genauso. 
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Betrachten wir nun den vom Compiler erzeugten Assembler- 
Source: 


;:ts = 8 

global _c,2 


public _main 
main: 

link a5,#.2 
movem.l .3,-(sp) 

clr.w -2(a5) 


;Sinnlos!?! 

;weist Assembler an, zwei Bytes für 
;_c zu reservieren. Ähnlich wie 
;"_c: ds.b 2“ 

;_main ist für alle Module bekannt 
;"genauso wie _c'' 

;a5 nach -(sp), sp nach a5, sp + #.2 
;Register auf Stack (keine Register 
;Liste angegeben!) Variablen-Stack 
;Zugriff auf Variable j 


.4 

movem.l (sp)+,.3 ;gerette Registerinhalte vom Stack 

;zurück an Register 

unlnk a5 ;a5 nach sp,-(sp) nach a5 

rts 


.2 equ -2 
.3 reg 

public _proc 
link a5,#.9 
movem.l .10,-(sp) 
clr.w _c 

.11 ’ 

movem.l (sp)+,.10 

unlnk a5 

rts 

.9 equ -2 
.10 reg 

public .begin 

dseg 

end 


;2 Bytes für Int-Objekt 
;zu rettende Register (Liste leer) 
;proc ist für alle Module bekannt. 
;Variablen-Stack anlegen 
;Register retten 
;c = 0 


;2 Bytes für i 

;keine zu rettenden Register 
;Beginn des Datensegmentes 


Der Variablenspeicher für Variablen aus Prozeduren wird also 
vom Stack geholt, während der Speicher für globale Variablen, 
die außerhalb von Funktionen definiert wurden, "normalen" 
Speicherplatz belegen. Bei Strukturen und Arrays sieht diese De¬ 
klaration ähnlich aus - nur mit mehr zu reservierenden Bytes. 
Bei Unions hingegen wird nicht für jede in der Union enthal¬ 
tene Variable Speicher reserviert, sondern nur soviel, wie die 
"größte" Variable der Union benötigt. Beim Zugriff auf ein 
Union-Element wird auf diesen Speicherbereich zugegriffen: 
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Union zahl 
C 

1 nt 1 ; 
float f; 

> 

Union zahl z; 

mainO 

i 

z.f = 1.1; 
z.i = 10; 

> 

Maschinensprache: 


global _z,4 

public _main 
main: 

link a5,#.2 
movem. l .3,-(sp) 
move.l #$8ccccd41,_z 

move.w #10,__z 

movem.l -(sp),.3 

unlk a5 

rts 

.2 equ 0 
.3 reg 

public .begin 

dseg 

end 


;Bytes für Union reservieren 
;(global) 


;z.f = 1.1 (float representation); 
;z.i =0 


;keine lokalen Variablen 


Beim Zugriff auf ein Struktur- oder Array-Element muß neben 
der Anfangsadresse der Struktur bzw. des Arrays auch noch der 
Offset des angesprochenen Elements berechnet werden: 
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C: 


mainO 

C 

struct Struktur 
C 

int Elementi; 
long Element2; 
float Elements; 

> 

struct Struktur s; 
struct Struktur t; 

s.Elementi = 0; 

s.Element2 = s.Elements; 

s=t; 

> 

Maschinensprache: 


public _main 
main: 


link a5,#.2 
movem.l .S,-(sp) 
clr.w -10^5) 

;s.Elementi = 0 

move.l -4(a5),d0 
jsr Ff ix# 
move.l do,-8<a5) 

;s.Elements -> dO 
;float nach long konvertieren 
;d0 -> s.Element2 

lea -10(a5),a0 
lea -20(a5),a1 
move.l (a1)+,(a0)+ 
move.l (a1)+,(a0)+ 
move.w (a1)+,(a0)+ 

;&s nach aO 
;&t nach a1 
;Bytes umschaufeln 

movem.l (sp)+,.S 

unlk a5 

rts 



.2 equ -20 
.S reg 

public .begin 

dseg 

end 

Wie Sie sehen, benutzt dieses Programm Variablen des Typs 
"float". Das Programm muß deshalb mit der Option +fi compi- 
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liert werden. Bei der Verwendung von double-Variablen muß 
die Option +ff benutzt werden. Bei der Benutzung des 68881- 
Mathe-Coprozessors müssen Sie Ihre Programme mit der +f8- 
Option compilieren. Da in allen drei Fällen Mathe-Routinen 
benötigt werden, die in der c.lib nicht enthalten sind, muß die 
m.lib, ma.lib bzw. mx.lib neben der c.lib zum Objekt-File ge¬ 
linkt werden. 

Wir wollen uns aber nun den schon oben angesprochenen Spei¬ 
cherklassen zuwenden: Mit der Speicherklasse "extern" sagen Sie 
dem Compiler, daß die Variable in einem anderen Modul zu 
finden ist. An dieser Stelle muß der Compiler also keinen Spei¬ 
cherplatz für diese Variable deklarieren, da dies in einem ande¬ 
ren Modul geschehen muß. Geschieht dies allerdings nicht, so 
meldet sich der Linker zu Wort, der eine "unresolved reference" 
- einen ungelösten Zugriff - erkennt. 

Benutzen Sie die extern-Anweisung bei der Variablendefinition 
bzw. -deklaration innerhalb einer Prozedur, so wird die globale 
Symboltabelle nach der geforderten Variablen durchsucht. Wenn 
Sie solch eine globale Variable benutzen wollen, sollten Sie im¬ 
mer die Speicherklasse "extern" bei der Deklaration angeben. So 
wissen Sie immer, welche Variablen in der Prozedur benutzt 
werden; welche lokal und welche global sind: 

int i; 
procO 
C 

extern int i; /* Zugriff aus globale i (Deklaration) */ 

int j; f* lokales (auto) j (Definition) V 


> 

Die Speicherklasse "static" gibt dem Compiler Aufschluß über 
die Art des Speichers, die für eine Variable verwendet werden 
soll. Normalerweise sind alle Variablen einer Prozedur "auto". 
Das heißt, daß der Speicherplatz bei Eintritt in die Funktion al- 
lokiert wird (vom Stack) und beim Austritt aus der Funktion 
wieder freigegeben wird. Legen Sie nun fest, daß eine Variable 
"static" ist, so wird der Speicherplatz für die Variable vom nor¬ 
malen Programmspeicher genommen. Beim Austritt aus einer 
Prozedur bleibt der Wert der Variablen erhalten, so daß Sie bei 
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einem eventuellen Wiedereintritt mit dem alten Variablenwert 
rechnen können. Für die Zuweisung des static-Speicherplatzes 
wird die bss-Direktive des Assemblers verwendet. Diese funk¬ 
tioniert ähnlich wie die global-Anweisung, nur daß der Spei¬ 
cherplatz für die Routine, in der die static-Variable definiert 
wurde, gültig ist. Dies wird dadurch erreicht, daß auf diese Va¬ 
riable nicht mit ihrem Namen - wie bei global _c,2 - sondern 
mit einem ganz normalen Label (z.B. .4) zugegriffen wird. 

Insbesondere in rekursiven Prozeduren machen sich static-Vari- 
ablen nützlich. Dort können sie z.B. als Zähler dienen, oder zur 
schnellen Weitergabe von Parametern, ohne daß diese über den 
Stack ausgetauscht werden müssen (siehe 2.1.4). 

Bei der Speicherklasse "register" wird ein Register zur Speiche¬ 
rung eines Variablenwertes herangezogen. Grundsätzlich kann 
man jeden skalaren Variablentyp als register-Variable definie¬ 
ren. Doch sollte man beachten, daß bei Double-Variablen, die 
die Speicherklasse "register" haben, notwendigerweise einige By¬ 
tes abgeschnitten werden müssen. Double-Variablen sind näm¬ 
lich 8 Bytes breit, aber die Adreß- und Datenregister des 
68000er können nur 4 Bytes aufnehmen. 

Die Register DO, Dl, D2, D3, A2 und A3 können vom Compiler 
zum Speichern von Werten benutzt werden. 


2.1.3 Die Übersetzung der Steueranweisungen 

Widmen wir uns nun den Steueranweisungen. Sie bestimmen, in 
welcher Reihenfolge verschiedene Routinen und Befehle abgear¬ 
beitet werden sollen. 

Nachdem nämlich die Fehleruntersuchung keine (offensichtli¬ 
chen) Fehler zutage gebracht hat und alle Variablen und Struk¬ 
turen untersucht und angelegt wurden, startet der eigentliche 
Compilier-Vorgang, der die einzelnen C-Befehle und Prozedur¬ 
aufrufe in Maschinensprache übersetzt. Zunächst wollen wir die 
Kontrollstrukturen (For, While, Switch, If) "übersetzen": 
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for (1=0;i<5; 1 ++) j += 2; 

Übersetzt sieht diese Programmsequenz so aus: 


clr.l -4(a5) 


* i=0 (Initialisierung von 

* i) 


,1: add.l #2,-8(a5) 


♦ j += 2 (Schleifenrumpf) 


add.l #1,-4(a5) 
cmp #5,-4(a5) 
blt .1 


* i++ (Inkrementierung) 

* i<5 (Abbruchbedingung) 

* ja, dann zurück zum Anfang 


Zunächst stößt der Compiler auf das "Wörtchen" "for". Dies sagt 
ihm, daß er es mit einem Schleifenbefehl zu tun hat. Doch im 
Gegensatz zu While wird bei For die Abbruchbedingung erst 
dann überprüft, wenn der Schleifenrumpf ausgeführt wurde. Bei 
While wird hingegen die Abbruchbedingung vor dem Eintritt in 
den Schleifenrumpf überprüft. 


Hat der Compiler diesen Befehl erkannt, wird die Initialisierung 
der Variablen i untersucht. Der Compiler stellt fest, daß die Va¬ 
riable i auf 0 gesetzt werden soll. Dies schlägt sich in dem Ma¬ 
schinensprachebefehl clr.l -4(a5) nieder. Es wird angenommen, 
daß der Speicherplatz der Variablen i in -4(a5) reserviert worden 
ist (Stack-Speicherplätze). Die Variable j befindet sich in -8(a5). 

Nach der Initialisierung der Variablen i muß sich der Compiler 
nun um den Schleifenrumpf, also um den Befehl j += 2 küm¬ 
mern. Die Abbruchbedingung und die Inkrementierung der Va¬ 
riablen i bleiben noch außer acht. Der Compiler geht nun zum 
Befehl j += 2 über. Da dies der erste (und einzige) Befehl ist, 
der im Schleifenrumpf enthalten ist, muß vor diesen Befehl ein 
Label, eine Sprungmarkierung, gesetzt werden, damit er wieder¬ 
holt angesprungen werden kann. Nach dem Setzen der Sprung¬ 
markierung wird der eigentliche Befehl übersetzt (add.l #2,- 
8(a5)). Nun muß der Compiler sich der Inkrementierung der 
Variablen i widmen (add.l #l,-4(5)) und die Abbruchbedingung 
untersuchen (cmp.l #5,-4(a5); blt .1). 


Hier können Sie schon erkennen, daß die Linearität der C-Be- 
fehle in Maschinensprache erhalten bleibt - nur in umgekehrter 
Richtung. 



Der Compiler unter der Lupe 


83 


Der Schleifenrumpf wird vor der Inkrementierung von i und 
diese vor der Abbruchbedingung übersetzt. Dies läßt auf einen 
rekursiven Algorithmus schließen. Trifft der Compiler auf die 
Initialisierung der Variablen i, befindet er sich auf Rekursi¬ 
onsstufe 1. Da die Initialisierung der Variablen i vor den 
Schleifendurchläufen geschehen sein muß, wird diese sofort 
übersetzt (clr.l -4(a5)). Dann gelangt der Compiler zur Abbruch¬ 
bedingung auf Rekursionsstufe 2. Nach der Abbruchbedingung 
gelangt er zur Inkrementierung von i auf Stufe 3, und danach 
auf Stufe 4 zum Schleifenrumpf. 

Bis jetzt wurde aber noch nichts übersetzt. Der Compiler ist nur 
bis zum Rumpf, der ja in der Schleife mehrmals ausgeführt 
werden soll, herabgestiegen. Da nach dem Rumpf nichts mehr 
folgt, wird zunächst dieser vollständig übersetzt. Danach werden 
die Inkrementierung (Ebene 3) und die Abbruchbedingung 
(Ebene 2) übersetzt. 

Natürlich ist der Rumpf einer solchen Schleife nicht immer so 
unkompliziert wie in diesem Beispiel. Enthält der Rumpf z.B. 
weitere For-Schleifen, so geht das ganze Spiel der Rekursion 
von vorne los. Aber gerade diese Rekursivität beim Compilieren 
macht C zu einer der vielseitigsten, aber auch schwer zu be¬ 
herrschenden Programmiersprachen. Man kann z.B. in die Ab¬ 
bruchbedingung Funktionsaufrufe einbetten. 

Einfache Programme kann man schon nach wenigen Stunden 
Einarbeitungszeit schreiben. Aber Programme eines anderen 
Autors zu lesen, das erfordert sehr viel mehr als nur ein paar 
Stunden Einarbeitungszeit. Haben Sie jedoch einmal begriffen, 
wie ein Compiler sich durch komplizierte und verschachtelte 
Programme durcharbeitet, dann kann dabei eigentlich nichts 
mehr schiefgehen. 

Zurück zu den Kontrollstrukturen. So ähnlich wie die For- 
Schleife wird auch die While-Schleife übersetzt. Allerdings ar¬ 
beitet der Compiler hierbei nicht so "rekursivintensiv" wie bei 
For. Bei While wird die Bedingung, die direkt nach dem 
Schlüsselwort While angegeben wird, sofort übersetzt. Bevor der 
Schleifenrumpf ausgeführt wird, wird die Abbruchbedingung 
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getestet. Der Übersetzer merkt sich nur, daß er noch ein Label 
an das Ende des While-Rumpfes setzen muß, um bei Nichter¬ 
füllung der While-Bedingung den Schleifenrumpf überspringen 
zu können: 


\ = 0 ; 

while (i<5) 

< 

i += 2; 

1 ++; 

> 

Maschinensprache: 


/* Initialisierung muß selbst V 
/* vorgenommen werden */ 
/* While-Schleife V 

/* Schleifenrumpf V 


clr.l -4(a5) * i = 0; 


.1; cmp #5,-4(a5) 
bge .2 

add.l #2,-8(a5) 
add.l #l,-4<a5) 
bra .1: 


* i<5 

* nein 

* < j 2; 

* i ++; > 

* zurück zum Anfang der Schleife 


Der While-Befehl kann also in einem Durchgang, ohne Rekur¬ 
sion, übersetzt werden. Somit können Sie so viele Whiles in- 
einanderschachteln wie Sie wollen. For-Schleifen können Sie je¬ 
doch nicht beliebig schachteln. E>er Compiler stellt Ihnen eine 
Verschachtelungstiefe von 20 For-Schleifen zur Verfügung. Sie 
können aber mittels der Option -e die "Expressiontable" - die 
Ausdruckstabelle - vergrößern. Ein Eintrag reserviert 14 Bytes, 
so daß bei "-e80" 1120 Bytes für die Expressiontable reserviert 
werden. Diese 1120 sind übrigens der Default-Wert, den der 
Compiler ohne Änderung Ihrerseits zur Verfügung stellt. Wollen 
Sie die Expressiontable aber vergrößern, so müssen Sie mehr als 
80 Einträge belegen. 

Allerdings existiert noch eine zweite Art der While-Schleife: 
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C: 


i = 0; 
do i 

j+=2; 

i++; 

> while (i<5); 

Bei dieser While-Schleife wird der Rumpf wenigstens einmal 
ausgeführt, und erst nach der Ausführung wird die Schleifenbe¬ 
dingung überprüft. Auch hier geht die Übersetzung wieder li¬ 
near vor sich. Der Compiler muß nur an die Zeile, in der das 
”do” steht, ein Label setzen und dieses bei zutreffender Schlei¬ 
fenbedingung anspringen. 

Eine weitere Kontrollstruktur ist die Switch-Anweisung. Mit 
ihrer Hilfe können Sie ja bekanntlich eine aus mehreren Alter¬ 
nativen wählen. Eine typische Switch-Anweisung sieht z.B. so 
aus: 


switch (i) 

case 3: 

break; 

case 4: 

1 --; 

break; 

default: 

1=0; 

break; 

> 

Der Compiler macht daraus: 



move.l -4(a5),d0 
bra .4 

* 

Inhalt von i nach dO 

.6: 

add.l #1,>4(a5) 

* 

case 3: !+••'; 


bra .5 

* 

break; 

.7: 

sub.l #L-4(a5) 

* 

case 4: i--; 


bra .5 

ft 

break; 

.8: 

clr.l -4(a5) 
bra .5 

* 

default: i=0; 
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.4: sub.l #3,d0 
beq .6 
sub.l #1,d0 
beq .7 
bra .8 
.5: 

Zunächst überträgt der Compiler den Wert der Variablen i in das 
Datenregister dO. Weiter kümmert er sich zunächst nicht um die 
Variable i. Im weiteren Verlauf wird jeder Case-Break-Rumpf 
übersetzt, indem jeweils vor den ersten Befehl eines solchen 
Rumpfes ein Label gesetzt wird und die einzelnen Anweisungen 
übersetzt werden. Am Schluß eines jeden Rumpfes steht eine 
Verzweigung an die Stelle im Programm, die nach der Switch- 
Anweisung ausgeführt werden soll. 

Doch wie wird die Switch-Anweisung vom Compiler bearbeitet? 
Natürlich spielt auch hier die Rekursion eine große Rolle. 
Zunächst wird nämlich dafür gesorgt, daß die Variable i in das 
Datenregister dO übertragen wird. Auch die Verzweigung nach .4 
(bra .4) wird programmiert. 

Danach wird eine Rekursionsstufe herabgeschritten, nicht ohne 
im Hinterkopf zu behalten, daß von allen Case-Break-Rümpfen 
nach .5 gesprungen werden muß. In der ersten Rekursionsstufe 
werden alle Rümpfe übersetzt. Dann wird diese Rekursionssstufe 
beendet, und der Compiler befindet sich wieder am Anfang der 
Switch-Anweisung. Diese wird jetzt aber nicht wie die For- und 
While-Anweisungen überlesen, sondern auf die einzelnen Fälle 
untersucht. 

Liest der Compiler jetzt "case 3", so wird von dO der Wert 3 ab¬ 
gezogen und auf 0 getestet, und eventuell wird verzweigt. Beim 
zweiten Case wird nach dem Wert 4 gefragt. Damit nicht noch 
einmal der Wert der Variablen i in das Datenregister geladen 
und dann der Wert 4 davon abgezogen werden muß, berechnet 
der Compiler die Differenz des ersten und zweiten Case (3-4). 
Ist diese Differenz negativ (wie hier), so wird der Betrag dieser 
Differenz von dO abgezogen (sub.l #l,dO). Ist die Differenz po¬ 
sitiv, wird der Betrag jedoch addiert (add.l #l,dO). Danach kann 
dann wieder getestet werden, ob das Datenregister den Wert 0 
hat. 
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Fallen alle diese Case-Vergleiche negativ aus, wird automatisch 
der Default-Rumpf angesprungen (der nicht immer angegeben 
werden muß, dann wird aber einfach die Switch-Anweisung 
verlassen). 


Aber natürlich sieht eine Switch-Anweisung nicht immer so ge¬ 
ordnet aus wie die obige. Erstens können mehr als zwei Cases 
enthalten sein, und zweitens müssen diese nicht geordnet sein: 


switch (i) 

C 

case 1: 

i++; 

break; 

case 0: 
i--; 
break; 
case 6: 

1=0; 

break; 

case 2: 

i=0; 

break; 

> 

Abgesehen davon, daß dies nicht besonders elegant program¬ 
miert ist - der Compiler nimmt’s nicht übel. Doch wie geht er 
hier vor? An folgendem Assembler-Code wollen wir dies ver¬ 
deutlichen: 


move.l -4(a5),d0 
bra .4 

.6: add.l #1,-4(a5) 
bra .5 

.7: sub.l #1,-4(a5) 
bra .5 

.8: sub.l #1,*4(a5) 
bra .5 

.9: sub.l #1,-4(a5) 
bra .5 

.10: dc.w .7-.11-2 
dc.w .6-.11-2 
dc.w .9-.11-2 


♦ Inhalt von i nach dO 


* case 1: i 

* break; 

* case 0: i--; 

* break; 

* case 6: i--; 

* break; 

* case 2: i--; 

* break; 

* case 0: 

* case 1: 

* case 2: 


( 0 ) 

( 2 ) 

(4) 
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dc.w .5-.11-2 
dc.w .5-.11-2 
dc.w .5-.11-2 
dc.w .6-.11-2 
.4: cmp.l #7,d0 
bcc .5 
asl.l #1,d0 

move.w .10(pc,d0.w),d0 

. 11 : 

jmp (pc.dO.w) 

.5: 


* default: 

* default: 

* default: 

* case 6: (12) 

* default 

* dO * 2 


Wie Sie sehen, wird diese Switch-Anweisung ähnlich übersetzt 
wie die obige. Nur die Auswahl der einzelnen Fälle wurde hier 
etwas anders geregelt. 

Zunächst werden die Case-Rümpfe in der Reihenfolge übersetzt, 
in der sie im C-Programm auftauchten. Erst in der Sprungta¬ 
belle, die die Adressen (relativ zum PC) aller Case-Rümpfe ent¬ 
hält, werden sie in eine Reihenfolge gebracht. Die Offsets wer¬ 
den dann in der Reihenfolge der Cases, auf die sie "zeigen", sor¬ 
tiert und abgespeichert. 

Sie können unter normalen Umständen maximal 100 Case-Be- 
dingungen abfragen. Sollten Sie einmal mehr Fälle abfragen 
wollen - was allerdings sehr unwahrscheinlich scheint - so kön¬ 
nen Sie mit Hilfe der Option -Y Speicherplätze für weitere 
Case-Bedingungen anfordern. Mit -YlOO würden 100 Einträge 
für die Case-Bedingungen reserviert. Ein Eintrag besteht dabei 
aus 4 Bytes, wobei 2 Bytes für den Offset und die anderen bei¬ 
den Bytes für die Integer-Zahl, die bei Case getestet werden 
soll, benötigt werden. 

Bei der Auswahl einer Case-Bedingung wird der Wert der Va¬ 
riablen i (enthalten in dO) verdoppelt (linksshift) und als Index 
auf diese Sprungtabelle verwendet. Da diese Tabelle nur aus 
Offsets besteht, die in WORDs angegeben werden, muß i nur 
verdoppelt und nicht vervierfacht werden, wie es z.B. nötig ge¬ 
wesen wäre, wenn die Tabelle aus den absoluten Adressen der • 
Case-Rümpfe bestünde. 

Da einige Fälle nicht abgefragt werden (case 3:, case 4:, case 5:), 
wird die Sprungtabelle an diesen Stellen mit der Adresse des 
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Befehls, der nach der Switch-AnweiSung ausgeführt werden soll 
(Label .5), auf gefüllt. 

Liegen die Fälle, die getestet werden sollen, allerdings sehr weit 
auseinander, so werden diese nicht durch eine Sprungtabelle aus¬ 
gewählt. Dies wäre ziemlich Speicher-uneffizient, da unter Um¬ 
ständen mehrere Male die Default-Adressen (zum Label .5) ab¬ 
gespeichert werden müßten. Deshalb greift man hier wieder auf 
die erste Methode zurück, überträgt die zu testende Variable in 
das Datenregister dO und subtrahiert bzw. addiert die verschie¬ 
denen CASE-Werte und testet dO auf 0. 

Doch kommen wir nun zur einfachsten Kontrollstruktur: Die If- 
Else-Anweisungen. Diese können so linear übersetzt werden, wie 
sie in C programmiert wurden: 

if (i == 1) i =0; 
eise 
i++; 

In Maschinensprache sieht das so aus: 

cnp.l #1,-4(a5) * i == 1 ? 

boe .4 • nein 

clr.l -4(a5) • ja 

bra .5 * weiter 

.4: add.l #1,-4(a5) * eise i++; 

.5: ... 

Das einzige Problem, das sich bei der Übersetzung der If-An- 
weisung stellt, ist das Label. Der Compiler merkt sich jedoch, 
welche Label-Nummer er z.B. einem Branch-Befehl angeben 
muß und welches Label vor einen Befehl geschrieben werden 
muß. 

Ein weiteres Problem stellt sich jedoch bei der Auswertung ma¬ 
thematischer Terme. Wie geht der Compiler z.B. mit "i = 
(j*5)+20" um? Auch hier spielt die Rekursion wieder eine große 
Rolle. Der Compiler arbeitet sich auf die unterste Klammere¬ 
bene vor, rechnet die Klammer aus und benutzt das Ergebnis 
für die Berechnung der nächsthöheren Klammerebene. 
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Dies jetzt im einzelnen zu beschreiben, würde an dieser Stelle zu 
weit führen. Es sei jedoch soviel gesagt: sind Sie sich nicht si¬ 
cher, welche Operation Priorität vor einer anderen hat, so sollten 
Sie lieber ein paar Klammern mehr setzen. Dadurch stellen Sie 
die Portabilität Ihres Programms sicher, auch wenn ein anderer 
Compiler vielleicht mathematische Ausdrücke etwas anders 
übersetzt. 

Eine weitere Steueranweisung, die allerdings nicht den Gefallen 
der Prozedural-Freunde findet, ist die Goto-Anweisung: 

goto Label; 


Label: ... 

Dabei wird einfach ein bra- oder jmp-Befehl für das As¬ 
sembler-Source generiert. Allerdings ist zu beachten, daß das 
Label, das angesprungen werden soll, in derselben Prozedur steht 
wie der Goto-Befehl. 


2.1.4 Der Aufruf von Prozeduren 

Neben den Steueranweisungen kann man natürlich auch eigene 
Prozeduren schreiben oder schon vorhandene benutzen. Dabei ist 
zu beachten, daß es zwei Arten von Prozeduren gibt: 

1. Funktionen, die einen Rückgabewert liefern. 

2. Routinen, die keinen Rückgabewert liefern. 

Beiden gemeinsam ist, daß ihnen Parameter übergeben werden 
können. Dabei ist zu beachten, daß die Parameter über den 
Stack übergeben werden, z.B: 

functi.j.k) 
i nt i; 
long j; 

struct Nonsense *k; 

{ 


> 


int l; 

1=0; func (i,k,k) 
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In Maschinensprache sieht diese - zugegebenermaßen etwas 
zwecklose - rekursive Routine so aus: 


func: 

link a5.#.2 
movem.l .3-(sp) 
move.l 14(a5),-(sp) 

move.l 10(a5),'(sp) 
move.l 8(a5),-(sp) 


;Speieher für lokale Variablen 
;Register auf Stack 
;Parameter k für erneuten 
; Aufruf auf Stack 
;j auf Stack 
;i auf Stack 


jsr __func 

lea 10(sp)«sp 
movem.l (sp)+,.3 
unlnk a5 
rts 


;Rout ine aufrufen 
;Stack restaurieren 
;Register wieder laden 
;Lokalspei eher frei geben 


.2 equ -2 
.3 reg 


; 2 wei Bytes für Int-Objekt 
;Registerliste 


Dazu vielleicht eine kleine Abbildung, die noch einmal verdeut¬ 
licht, wie die lokalen Variablen auf dem Stack abgelegt werden: 


Paran*t*r k 


leCaS) >> 

8C»3J -> 


-2CaS) -> 
SP -> 


Paranatar J 


Paranatar i] 


Rücksoruns' 

adrassa 

Cisr) 


aS 


Zaigar 


long 


link a5,K.2 


a3->-Cspl; 
a3 = spi ^ 
sp-> sp4^« . 2 

C.2 aqu -2) 


novan.1 .6.-CspJ 


Abbildung 2.1: Stack 
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Sie sehen, daß mit positiver Indexierung von a5 die Eingabe- 
Parameter angesprochen werden (z.B. 8(a5)), während mit nega¬ 
tiver Indexierung (-2(a5)) die lokalen Variablen, die auf dem 
Stack abgelegt werden, angesprochen werden. 

Zu beachten ist, daß beim Zugriff auf die Eingabe-Parameter 
der alte Registerwert von a5, der durch den LINK-Befehl auf 
dem Stack abgelegt wird, und die Rücksprungadresse, die bei 
jedem JSR abgespeichert wird, übersprungen werden müssen. 
Sonst ist nur noch zu beachten, daß die Eingabe-Parameter in 
umgekehrter Reihenfolge auf dem Stack abgelegt werden. 

Ein nicht zu unterschätzendes Problem stellt die Tatsache dar, 
daß der Compiler nicht überprüft, ob die richtige Anzahl von 
Parametern und die richtigen Typen an eine Routine übergeben 
wurden. 

Angenommen, eine Routine erwartet 3 Long-Variablen als Ein¬ 
gabe-Parameter, aber Sie übergeben dieser Routine nur 3 int- 
Werte. Die drei int-Variablen belegen nur 6 Stack-Bytes, wäh¬ 
rend in der Routine auf 12 Bytes (3*4 (long)) zugegriffen wird. 

Wenn Sie nun einen dieser Parameter verändern (im oberen 
Beispiel z.B. k=0 <=> clr.l 14(a5)), was in C durchaus möglich 
(und erlaubt?!?) ist, kann es passieren, daß Sie z.B. eine Rück¬ 
sprungadresse verändern, weil bei der Parameterübergabe nur 6 
statt der geforderten 12 Stack-Bytes belegt wurden. 

Doch wenden wir uns den Funktionen zu. Auch hier werden die 
Eingabe-Parameter auf dem Stack abgelegt. Dies geschieht ge¬ 
nauso wie bei den Routinen. Der einzige Unterschied zwischen 
Routinen und Funktionen besteht darin, daß Funktionen einen 
Rückgabe wert liefern. Der Typ des Rückgabewertes muß von 
Ihnen festgelegt worden sein, denn Sie können mit dem Rückga¬ 
bewert genauso weiterrechnen wie z.B. mit Variablen und Kon¬ 
stanten. 

Der Typ des Rückgabe wertes wird dabei bekanntlich vor dem 
Funktionsnamen angegeben. Allerdings gibt es bei den Funktio¬ 
nen auch den Typ "void", der besagt, daß diese Funktion keinen 
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Rückgabewert besitzt, also gar keine Funktion ist. Wird der Typ 
einer Funktion nicht von Ihnen festgelegt, so bestimmt der 
Compiler, daß diese Routine einen Rückgabe wert vom Typ "int" 
hat. Nur Prozeduren mit dem Rückgabewert "void" sind also 
wahre Routinen. 


Korrekte ParaneterUberoabe Falsche ParaneterUbergabe (nur Int's) 


14(a3) 


lOCaS) 

8(aS) 


-2Ca5) 



Paraneter k 

> 


> 

Paraneter j 

> 

Paran«t«r i 


Rücksprung¬ 

adresse 

Cjsr) 


a5 

> 

lokale 

Uariab 1en 


Zeiger 


1 ong 


l nt 


link aS,n . 2 





'-///// 

/ X / / / 

114 (äSJ 

12CaS) -> 

■Paraneter k 

lOCaS) -> 

Paraneter > 

8(a5) -> 

Paraneter i 


Riic k sprung- 
adresse 
Cjsr) 


a5 

-2Ca5) -> 

lokale 

Uariab 1en 


Abbildung 2,2: Stack und Parameterübergabe 


Der Typ des Rückgabe wertes einer Funktion wird genauso wie 
ein Variablentyp in der Symboltabelle abgespeichert: 

void Funktion 
Symboltabelle: 

"Funkt 1 on"/Code_für_Prozedur/Code_für_Void 

Wenn sich eine Funktion in einem anderen Modul oder in einer 
Bibliothek befindet, kann man den Typ einer solchen "externen" 
Funktion ähnlich festlegen wie den Typ einer "externen" Vari¬ 
ablen: 
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extern struct *MsgPort FindPortO; 

Symboltabelle: 

"FindPort"/Code__für_externe_Prozedur/Code__für_Struktur__typ/ 

"MsgPort"/ 

Sie können davon ausgehen, daß der Compiler nicht "meckert", 
wenn Sie den Rückgabewert von FindPortO, der ein Zeiger auf 
eine MsgPort-Struktur ist, an einen Zeiger des Typs MsgPort 
übergeben. Grundsätzlich spielen bei Zeigerzuweisungen die 
Objekte der beteiligten Zeiger keine Rolle. Zeigervariablen sind 
immer 4 Bytes lang, so daß bei Zuweisungen keinerlei Konver¬ 
tierungen vorgenommen werden müssen. Es gibt allerdings eine 
zweite Art von Zeigern - die BCPL- oder CPTR-Zeiger. Diese 
sind ein Überbleibsel der Sprache BCPL. Ihr Inhalt wird nur um 
2 Bits nach rechts geshiftet, so daß diese Zeiger nur auf Lang¬ 
wort-Adressen zugreifen können. BCPL-Zeiger kommen aller¬ 
dings nur als Eingabe-Parameter vor und das nur sehr selten, 
z.B. bei einigen I/O-Routinen. 

Funktionen in anderen Modulen können Sie mittels "extern"-De- 
klarationen auch andere Rückgabewerte zuweisen. Angenommen, 
die Routine atol() wird in Modul2 definiert und gibt eigentlich 
ein Lang-Wort zurück. Definieren Sie nun in Modull mittels der 
extern-Deklaration, daß diese Routine einen Rückgabe wert vom 
Typ "int" haben soll (extern int atol()), kann sich der Compiler 
nicht beschweren, da ihm die Symboltabelle für das zweite Mo¬ 
dul nicht zur Verfügung steht. Allerdings sollten Sie beachten, 
daß diese Deklaration vor Benutzung der Routine vorgenommen 
werden muß. Auch wenn Sie Ihre eigenen Funktionen schreiben, 
die nicht vom Typ "void" sind, müssen Sie darauf achten, daß 
diese vor Benutzung definiert (oder deklariert) werden, damit sie 
zur weiteren Benutzung in die Symboltabelle aufgenommen wer¬ 
den können. 

Bei Funktionen spielen die Typen der Eingabe-Parameter aller¬ 
dings keine Rolle. Es gibt aber Compiler, die auch die Eingabe- 
Parameter auf "Typenreinheit" überprüfen, so daß Fehler wie 
der oben beschriebene nicht auftreten können. Der Aztec-Com- 
piler jedoch gehört nicht zu diesen. 
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Vielleicht noch ein Wort dazu, wie der Rückgabewert Maschi¬ 
nensprache-technisch behandelt wird. Dieser wird im Datenregi¬ 
ster dO mittels der return()-Anweisung übergeben (auch Zeiger). 
Zu beachten ist hierbei, daß der Funktionstyp und der Typ der 
Variablen, die mit return() zurückgegeben wird, übereinstimmen. 


2.2 Der Assembler 


Nachdem der Compiler das Assembler-Source erzeugt hat, kann 
der Assembler (Aufruf: as [>Ausgabe-File] [Optionen] Pro- 
gramm.asm) mit seiner Arbeit beginnen. Er muß das Objekt-File 
aus dem Assembler-Source erzeugen. 

Das Objekt-File besteht dabei soweit wie möglich aus ausführ¬ 
barem Maschinen-Code. Nur die unaufgelösten externen Refe¬ 
renzen müssen noch mit Hilfe des Linkers gelöst werden. 


Betrachten wir dazu folgendes Assembler-Source: 


dseg 
ds 0 

public Str 
Str: 

dc.l ,1+0 
cseg 
dseg 

.1 dc.b 72,97,108108,111,0 
cseg 

global _i,2 
public _main 
__main: 

link a5,#.3 
movem.l .4,-(sp) 
add.l 1,_str ;str++; 
jsr _exit 
.5 


;Datensegtnent 
;0 Bytes reservieren 
;globle Variable 

;Speieher mit Adresse des Strings belegen 
;Codesegment 
;Datensegment 
;"Hai Io” 

;Codesegment 


;db hier geht's los 


movem.l (sp)+,.4 

unlk a5 

rts 


.3 equ 0 
.4 reg 


public _exit 
public .begin 
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dseg 

end 

Aus diesem Assembler-Source erzeugt der Assembler nun re- 
lokatiblen Code. Relokatibel bedeutet, daß das Programm an je¬ 
der beliebigen Stelle im Computer lauffähig ist. Es ist also nicht 
auf eine bestimmte Anfangsadresse festgelegt. 

Jedoch ist der Assembler-Source gar nicht so angelegt, daß es 
relokatiblen Code erzeugen würde. Dieser relokatible Code be¬ 
nutzt nämlich die Adressierung "Programmzähler relativ mit 16- 
Bit-Adreßdistanzwert" (z.B. jmp $10(pc)). Das Assembler-Source 
enthält aber nur Befehle mit absoluter Adressierungsart (z.B. jsr 
_exit). 

Beim Assemblieren aber werden diese absoluten Befehle in rela¬ 
tive umgewandelt. Dabei spielen allerdings die beiden Direktiven 
"public" und "global" eine Rolle. Diese sorgen nämlich dafür, daß 
das angegegebene Label in die sogenannte Label-Tabelle aufge¬ 
nommen wird, in der alle globalen Label des Moduls stehen. 

In einem ersten Durchgang untersucht der Assembler das Pro¬ 
gramm auf solche Label. Gleichzeitig untersucht er, ob ein Label 
der Label-Tabelle eine Entsprechung im Assembler-File findet. 
Dies ist z.B. bei main der Fall. Zunächst wird dieses Label in die 
Label-Tabelle aufgenommen (public _main) und dann definiert 
(_main:). global _i,2 sorgt dafür, daß das Label _i in die La¬ 
bel-Tabelle aufgenommen wird. Der Speicherplatz für diese Va¬ 
riable wird aber erst vom Linker zur Verfügung gestellt. (Die 
Direktive bss reserviert auch Speicher für eine Variable. Nur 
wird das Label, das mit diesem Speicherplatz assoziiert wird, 
nicht in die Label-Tabelle aufgenommen. Somit eignet sich bss 
sehr gut für die Anlage von Static-Variablen innerhalb von 
Funktionen.) 

Greift nun ein Befehl auf eine mit einem Label spezifizierte 
Speicherstelle zu, so wird anhand der Label-Tabelle untersucht, 
ob dieses Label im gleichen Modul definiert wurde. Ist dies der 
Fall, kann der Adreßdistanzwert von der augenblicklichen Posi¬ 
tion zum Label berechnet und für den Befehl eingesetzt werden. 
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Bei der Berechnung des Adreßdistanzwertes ist es allerdings 
wichtig zu wissen, ob das Label eine Speicherstelle im Code- 
Segment oder eine Speicherstelle im Datensegment beschreibt. 
Aus dem ersten Durchgang des Assemblierens weiß der As¬ 
sembler, wie viele Bytes das Programm enthalten wird. Greift 
man mit einem Befehl dann auf ein Label im Datensegment zu, 
so muß beachtet werden, daß das Datensegment an das Code- 
Segment angehängt wird. 


Code- und Datensegment sind zwei getrennte Bereiche. Steht vor 
einem Befehl des Assembler-Sources die Direktive dseg, so wer¬ 
den alle nachfolgenden Daten in das Datensegment geschrieben, 
bis ein cseg folgt, das den Beginn des Code-Segments beschreibt. 


Im folgendem Listing können Sie genau sehen, daß Code- und 
Datensegment zwei getrennte Bereiche sind. Immer, wenn die 
Direktive dseg oder cseg auftaucht, ändert sich die Adresse in 
der zweiten Spalte (der Code-Segment- bzw. Daten-Segment- 
Programmzähler). 

Aztec 68000 Assembler 3.4a 1-25-87 


1 0000: 
2 0000: 

3 0000: 

4 0000: 

5 0000: 

xxxx xxxx 

dseg 
ds 0 

public _str 
str: 

dc.l .1+0 

6 0004: 

7 0000: 

8 0004: 

9 0004: 

4861 

o 

o 

o 

o 

cseg 

dseg 

.1 

dc.b 72,97,108,108,111,0 

10 000a: 

11 0000: 
12 0000: 

13 0000: 

14 0000: 

4e55 

0000 

cseg 

global _i,2 
public _main 
main: 

link a5,#.3 

15 0004: 

16 0004: 

52ad 

xxxx 

movem.l .4,-(sp) 
add.l #1,_str 

17 0008: 

4eba 

xxxx 

jsr exit 

18 000c: 

19 r^Oc: 

20 000c: 

4e5d 


.5 

movem.l (sp)+,.4 
unlk a5 

21 OOOe: 

4e75 


rts 

22 0010: 

0000 

0000 

.3 equ 0 

23 0010: 

0000 


.4 reg 

24 0010: 

25 000c: 



public _exit 
public .begin 
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26 000c: dseg 

27 000a: end 

Dieses Listing ist das mit der Option -1 erzeugte Listing des obi¬ 
gen Assembler-Files. Hier können Sie ganz genau erkennen, daß 
der Assembler die absolut adressierenden Befehle in relativ 
adressierende Befehle umwandelt. 

Der Maschinen-Code (Hex-Code) für "jmp _exit" wäre $4eb9. 
Im Listing (Zeile 17) steht für "jmp _exit" aber der Hex-Code 
$4eba. Dieser steht für jsr XXXX(pc). Der Offset zur Routine 
_exit kann noch nicht bestimmt werden, da diese Routine nicht 
in diesem Modul definiert ist. 

Deshalb setzt der Compiler für diesen Offset einen Querverweis 
ein, der auf das Label _exit der Label-Tabelle zeigt, die im 
Objekt-File mit abgespeichert wird. 

Dieses Listing wird im ersten Pass des Assemblers erzeugt. Dies 
ist daran zu erkennen, daß in Zeile 5 lauter x stehen. Dies ge¬ 
schieht deshalb, weil im ersten Pass noch nicht bekannt ist, an 
welcher "Speicherstelle" der String im Datensegment steht. 

Ähnlich ist es in Zeile 16 (add.l #l,_str). Da der Beginn des 
Datensegments noch nicht feststeht, kann der Offset zur Vari¬ 
ablen _str noch nicht berechnet werden. 

Das Objekt-File, das der Assembler erzeugt, besteht nun aus 
dem soweit wie möglich ausführbaren Maschinen-Code, einem 
Header, der die Größe des Programms, die Anzahl der Labels in 
der mit abgespeicherten Label-Tabelle etc. angibt, und aus der 
Label-Tabelle: 
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Header 


Code-Seonent 



Abbildung 2.3: Label 

Doch betrachten wir noch einmal das Listing und den As¬ 
sembler-Source. Beim Vergleich fällt auf, daß der Assembler die 
Befehle movem.l .4,-(sp) (in Zeile 15) und movem.l -(sp),.4 (in 
Zeile 19) nicht übersetzt. 

Diese Befehle hat der Assembler "wegoptimiert", da sie offen¬ 
sichtlich sinnlos sind. Die Befehle haben nur dann eine Aufgabe, 
wenn Register zu retten sind. Dies ist aber höchstens dann der 
Fall, wenn Register-Variablen benutzt werden. 

Diese Optimierung ist allerdings nicht die einzige, die der Com¬ 
piler durchführt. So werden z.B. Verzweigungen zum nächsten 
Befehl eliminiert; 

bra .7 

.7 ... 

Diese Konstruktion ist ja auch sinnlos, da der Befehl beim Label 
.7 sowieso, auch ohne den Branch-Befehl, ausgeführt wird. 
Weiterhin werden alle jsr-Befehle soweit wie möglich durch bsr- 
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Befehle ersetzt. Diese sind schneller in der Ausführung und sor¬ 
gen somit für ein kleines Speed-Up Ihres Programms. 

Jedoch ist die Option -n nicht die einzige Assembler-Option: 


Assembler-Optionen 

-OFilename 

Der Objekt-Code wird in das hier angegebene File geschrieben. 
-IDirectory 

Diese Option legt wie beim Compiler fest, welches Unterver¬ 
zeichnis nach Include-Files durchsucht werden soll. 

-L 

Diese Option veranlaßt den Assembler, ein Listing des As- 
sembler-Sources zu erzeugen. Das Listing wird im ersten Pass 
des Assemblers erzeugt, in das File Filename.Ist geschrieben und 
kann mit dem Editor ED untersucht werden. 

-N 

Der Objekt-Code wird nicht optimiert. 

-SNummer 

Es wird eine Squeeze-Tabelle mit Nummer Einträgen erzeugt. 
Ein Eintrag ist ein Byte groß. Ohne Angabe der Größe der Ta¬ 
belle werden vom Assembler 1000 Bytes (Einträge) reserviert. 
Die Squeeze-Tabelle wird für die Optimierung des Objekt-Codes 
benötigt. 

-V 

Es wird eine Speicherverbrauchs-Statistik ausgegeben (Verbose- 
Option). 

-ZAP 

Das angegebene Assembler-Source-File wird nach dem Assem- 
blieren gelöscht. 
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-C 

Es wird "large Code" erzeugt (siehe Kapitel 2.3). 

-D 

Es wird "large data" erzeugt. 

-ENamef=Wert ] 

Dem Symbol Name wird der angegebene Wert zugewiesen. Diese 
Zuweisung beim Assembler-Aufruf kommt einem "Name EQU 
Wert” gleich. Der Wert kann optional angegeben werden. Wird er 
nicht explizit angegeben, bekommt das Symbol den Wert 1. 


2.3 Der Linker 

Die Aufgabe (Aufruf: ln [>Ausgabe-File] Objektfiles.o 
[Optionen]) des Linkers besteht nun darin, die unaufgelösten 
Referenzen der einzelnen Module zu lösen. Dazu werden die 
Objekt-Files (Module) zumeist mit den Linker-Librarys gelinkt. 

Betrachten wir dazu noch einmal das letzte Programmbeispiel. 
Dort wurde die Routine _exit auf gerufen. Diese Routine wurde 
aber nicht in dem Modul definiert, in dem sie auf gerufen 
wurde. Die Definition von _exit erfolgt in der Linker-Library 
c.lib. Diese muß also mit dem Objekt-File, das den _exit-Auf- 
ruf enthält, gelinkt werden. 

Dabei liest der Linker zunächst das Objekt-File ein. Dann un¬ 
tersucht der Linker die Label-Tabelle des Objekt-Files. Aus der 
Label-Tabelle erfährt er, daß _exit eine unaufgelöste externe 
Referenz ist. Dies vermerkt der Linker in einer weiteren Ta¬ 
belle, in der alle ungelösten Referenzen aufgelistet werden. Wird 
nun in einem Modul eine dieser unaufgelösten Referenzen ge¬ 
löst, wird dies in der Tabelle der unaufgelösten Label vermerkt. 

Nun untersucht der Linker die aneinandergereihten Module. Bis 
jetzt sind nämlich z.B. die Befehle, die eine externe Routine 
aufrufen, noch nicht vollständig. Zwar existiert z.B. schon der 
Hex-Code für den PC-relativen JSR-Befehl, aber der Offset der 
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Routine, die angesprungen werden soll, ist noch nicht bekannt. 
Diese Offsets können aber in einem zweiten Durchgang errech¬ 
net und an die jeweiligen Stellen eingetragen werden. 

Betrachten wir dazu das zweite Listing in diesem Kapitel. In 
Zeile 17 erkennen Sie den Befehl jsr _exit. Der Assembler hat 
für diesen Befehl den Hex-Code $4eba xxxx generiert, jsr _exit 
belegt eigentlich 4 Bytes. Der Assembler benutzt aber zunächst 
nur 2 Bytes - nämlich die, die für die Codierung des PC-relati¬ 
ven JSR’s verwendet werden ($4eba). Die restlichen zwei Bytes, 
die die Adreßdistanz für diesen Befehl angeben, bleiben 
zunächst uninitialisiert. Diese Initialisierung übernimmt der Lin¬ 
ker, der im zweiten Durchgang alle benötigten Offsets errechnen 
und in die jeweiligen Stellen eintragen kann. 

Kommen wir nun aber zu einer Frage, die Sie sich sicher auch 
schon gestellt haben: Werden beim Linken eines Objekt-Files mit 
einer Linker-Library alle Funktionen der Linker-Library oder 
nur die vom Objekt-File tatsächlich angesprochenen Funktionen 
eingebunden? Hier geht der Aztec-Linker sehr ökonomisch vor. 
Er hängt an Ihr Programm nur die tatsächlich verwendeten 
Routinen an, während er beim Linken zweier Objekt-Files alle 
Funktionen zusammenbindet. 

Doch auch hier stellt sich eine entscheidende Frage: Wenn man 
nämlich dem Linker sowohl durch ln OFile.o -lram:c als auch 
durch ln OFile.o ram:c.lib dazu veranlassen kann, ein Modul 
bzw. Objekt-File mit der c.lib zu linken, und die c.lib nur ein 
Objekt-File ist, das sehr viele Funktionen enthält, wieso werden 
dann an das OFile nur die Routinen der c.lib angehängt, die 
tatsächlich benötigt werden, und nicht die gesamte c.lib? 

Hierzu läßt sich sagen, daß die Linker-Librarys keine Objekt- 
Files im Sinne der Files sind, die vom Assembler erzeugt wer¬ 
den. Die Linker-Librarys bestehen nämlich aus einem Zusam¬ 
menschluß mehrerer normaler Objekt-Files. Allerdings sind 
diese Librarys in einer etwas anderen Art und Weise geordnet. 
Während nämlich in herkömmlichen Objekt-Files die Label-Ta¬ 
belle an das Ende des Files gestellt wurde, steht diese bei den 
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Linker-Librarys am Anfang. Dann erst folgt der ausführbare 
Maschinen-Code. 

Soll der Linker nun eine Library zu einem Objekt-File linken, 
was wohl fast immer der Fall sein dürfte, so erkennt er an ei¬ 
nem speziellen Code zu Anfang der Library, daß er eine Library 
und nicht ein normales Objekt-File untersucht. Der Linker un¬ 
tersucht nun also die Label-Tabelle der Library. Mit Hilfe dieser 
kann er sofort die ungelösten externen Referenzen der Objekt- 
Files lösen. Er merkt sich dabei auch, welche Routinen der Li¬ 
brary benutzt wurden. 

Wenn der Linker die Label-Tabelle der Library durchgelesen 
hat, kommt er zum ausführbaren Code der Library. Er "greift" 
sich diejenigen Funktionen heraus, die er sich oben gemerkt hat, 
und hängt sie an die normalen Objekt-Files an. Im zweiten 
Durchgang kann er dann alle benötigten Offsets berechnen und 
einsetzen. 

Doch ist der Linker nicht nur für die Lösung der ungelösten 
externen Referenzen zuständig. Er sorgt auch dafür, daß der so¬ 
genannte Startup-Code zu den Objekt-Files gelinkt wird. Dies 
wird durch die Maschinensprache-Anweisung public .begin be¬ 
wirkt. .begin wird im ersten Durchgang in die Liste der unauf¬ 
gelösten Referenzen aufgenommen, und im Verlauf - beim Lin¬ 
ken der c.Lib - an das Programm angehängt. 

Weiterhin wird für jedes Modul bzw. Objekt-File, das die An¬ 
weisung public .begin enthält, der Maschinensprache-Befehl jmp 
.begin erzeugt (natürlich in PC-relativer Form). Dies ist aller¬ 
dings nur für das erste der zu linkenden Objekt-Files not¬ 
wendig. Dieser Befehl muß der erste des ganzen Programms sein. 
In den anderen Modulen nimmt dieser Befehl aber nur Speicher¬ 
plätze (jeweils 4 Bytes) weg. Deshalb sollten Sie bei der Ver¬ 
wendung mehrerer Module dafür sorgen, daß nur beim ersten 
Modul das Label .begin "publiziert" wird. Alle anderen Module 
sollten Sie mit der +b-Option compilieren. 

Doch kommen wir dazu, welche Aufgabe der Startup-Code hat. 
Zunächst einmal werden von diesem Startup-Code die DOS- und 
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die MathFFP-Library geöffnet. Dann hat der Startup-Code zu 
unterscheiden, ob das Programm von der Workbench aus oder 
vom CLI gestartet wurde. 

Beim Start von Workbench muß zunächst auf die Startup-Mes- 
sage gewartet werden. Werden mit dieser Message Parameter 
übergeben, so werden diese als Lock-Struktur interpretiert und 
dazu benutzt, das gelockte Directory als das aktuelle Directory 
zu kennzeichnen. Dann wird, falls erforderlich, das Tooltype- 
Window geöffnet und zur Standard-Ein-/Ausgabe deklariert. 

Beim Start vom CLI aus wird nur dafür gesorgt, daß der Be¬ 
nutzer die Anzahl der Parameter und die Adresse auf das Para¬ 
meter-Array erhält. Diese werden vom DOS über den CIS 
(Command Input String) zur Verfügung gestellt. Der Startup- 
Code für das CLI muß die Parameter nur noch so aufbereiten, 
daß sie durch main (arge, argv) übergeben werden können. 

Nach der Aufbereitung des Parameter-Strings wird die Routine 
main des C-Programms wie eine Prozedur aufgerufen. Irgendwo 
im Startup-Code, der teilweise in Maschinensprache und teil¬ 
weise in C verfaßt wurde, taucht der C-Befehl main(argc, argv); 
auf. Direkt danach aber steht der C-Aufruf _exit(0);. Dieses 
_exit() sorgt dafür, daß die DOS- und MathFFP-Library ge¬ 
schlossen werden, der in Zusammenhang mit der Aufbereitung 
der Kommando-Parameter belegte Speicherplatz freigegeben, 
und der Befehl exit() aufgerufen wird. Dieses exit() ist genau die 
Routine, mit der Sie Ihr Programm zum frühzeitigen Abbruch 
bewegen können. 

Doch befassen wir uns wieder mit den Linker-Librarys. Da der 
Startup-Code immer zu einem C-Programm gelinkt werden muß, 
muß die c.lib immer ein Bestandteil Ihres Programms sein. Es 
gibt aber noch andere Librarys. Zum Beispiel die m.lib. Diese ist 
immer dann zum Objekt-File zu linken, wenn in diesem mit der 
Fließkomma-Arithmetik gearbeitet wird. Allerdings reicht es 
nicht, bei der Verwendung der Fließkomma-Routinen einfach 
diese Linker-Library zum Objekt-File zu linken. Weiterhin 
müssen Sie das Programm mittels der Compiler-Option +ff com- 
pilieren. Um die doppelt genaue Fließkomma-Arithmetik zu be- 
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nutzen, müssen Sie das Programm mit der Option +fi compilie- 
ren und mit der mx.lib linken. Bei der Verwendung des 68881- 
Floating-Point-Prozessors müssen Sie die m8.1ib benutzen und 
das Programm mittels +f8 compilieren. 

Aber auch die m.lib und c.lib sind nicht die einzigen Librarys 
des Compiler-Pakets. Haben Sie sich schon einmal auf den Dis¬ 
ketten umgesehen, so finden Sie z.B. dort auch eine c32.1ib, eine 
cl.lib und eine cl32.1ib. Auch die anderen Librarys treten in 
diesen Formen auf: ml.lib, m321.Iib etc. 

Die Linker-Librarys, die ein 1 in ihrem Namen haben, müssen 
zu den Objekt-Files gelinkt werden, wenn Sie das "large data"- 
und "large code"-Speichermodell verwenden wollen: 


2.3.1 Das “large data“- und “small data“-Modell 

Kommen wir zunächst zu den Unterschieden zwischen "large 
data" und "small data". Wie der Name schon sagt, beziehen sich 
diese beiden Speichermodelle auf das Datensegment. Beim "small 
data"-Modell kann das Datensegment nur 64 KByte groß sein. 
Dies liegt daran, daß hier der Zugriff auf die Daten über ein 
Adreßregister geschieht, das auf die Mitte des Datenbereichs 
zeigt, und durch negative und positive Offsets zwischen 0 und 
32768 nur 64 KByte "abgreifen" kann. Hier wird die "PC-relativ 
mit 16-Bit Adreßdistanzwert"-Adressierung benutzt. 

Beim "large data"-Modell hingegen wird nicht mit Offsets gear¬ 
beitet, wenn auf eine Speicherstelle im Datensegment zugegrif¬ 
fen werden soll. Hier wird über die absoluten Adressen auf die 
Daten zugegriffen. Da aber zunächst nicht bekannt ist, an wel¬ 
cher Speicherstelle das Programm beginnt, müssen nach dem La¬ 
den des Programms alle Befehle, die auf absolute Speicherstellen 
des Datensegments zugreifen, korrigiert werden. Dies ist der 
Grund, warum es länger dauert, bis ein "large data"-Programm 
anläuft. Auch ist der Zugriff auf absolute Speicherstellen lang¬ 
samer als der PC-relative Zugriff auf Speicherstellen. Der Vor¬ 
teil beim "large data"-Modell hingegen ist der, daß das Daten- 
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Segment nicht auf eine Größe von 64 KByte beschränkt ist, son¬ 
dern theoretisch den gesamten freien Speicher belegen kann. 


2.3.2 "large code" und "small code" 

Die Modelle "large code" und "small code" befassen sich, wie der 
Name schon sagt, mit dem Code-Segment des Programms. Aller¬ 
dings dreht es sich hier weniger um den ausführbaren Code als 
um die Daten, die auch im Code-Segment abgespeichert werden. 

Beim "large Code"-Modell dürfen Daten im gesamten Code-Seg¬ 
ment liegen, unter Umständen sogar über den gesamten Speicher 
verstreut. Das "small code"-Modell hingegen erlaubt nur, daß die 
Daten in einer Umgebung von 32 KByte um den Programm- 
Counter angelegt sind. 

Ist das "small code"-Programm allerdings größer, so wird für die 
Speicherbereiche außerhalb dieser 32 KByte eine Adreßtabelle 
mit absoluten Adressen angelegt, über die indirekt auf die 
außerhalb liegenden Speicherbereiche zugegriffen wird. 

Auch bei Verzweigungen außerhalb dieser 32 KByte wird mit 
einer Sprungtabelle gearbeitet. Doch nimmt die Korrektur dieser 
Sprung- und Adreßtabelle meist weniger Zeit in Anspruch als 
die Korrektur der Befehle eines "large code"-Programms, das ja 
ausschließlich absolute Adressierungen benutzt. Allerdings muß 
beim "small code"-Modell ein Adreßregister abgestellt werden, 
das in die Mitte des Daten-Segmentes reicht, während "large 
Code" absolut auf das Datensegment zugreift. Grundsätzlich ist 
die absolute 32-Bit-Adressierung auch langsamer als die 16-Bit- 
Adreßdistanzwert-Adressierung. 

Wollen Sie entweder "large code" oder "large data" verwenden, 
müssen Sie das Programm mit der Option +C bzw. +D com- 
pilieren imd assemblieren. Beim Linken müssen Sie dann in je¬ 
dem der beiden Fälle eine der Librarys mit einem 1 im Namen 
hinzu linken (z.B. cl.lib oder cl32.1ib). 
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Jetzt fragen Sie sich sicher, was es mit der 32 im Namen der 
c32.1ib bzw. cl32.1ib auf sich hat. Diese 32 steht für 32 Bit Inte¬ 
ger. Die in diesen Librarys verwendeten Int-Variablen sind nicht 
16, sondern 32 Bit breit. 

Dies ist insbesondere im Zusammenhang mit der Kompatibilität 
von Lattice- und Aztec-Programmen wichtig. Lattice-Pro- 
gramme übergeben nämlich keine 16-Bit-Int-Variablen. Vari¬ 
ablen und Konstanten werden vom Lattice-Compiler auf 32-Bit- 
Größe erweitert. Diese Erweiterung wird beim Aztec-Compiler 
nicht mehr durchgeführt, so daß bei Verwendung einer Int-Va- 
riable als Funktionsparameter tatsächlich nur 16 anstatt 32 Bit 
übergeben werden. Die Library-Routine verlangt aber 32 Bit 
und kann so unter Umständen Parameter falsch interpretieren 
oder gar Symstemabstürze veranlassen. 

Die ungenaue Lattice-Programmierung versucht man beim Az¬ 
tec-Compiler nun dadurch zu kompensieren, daß man alle Int- 
Variablen und alle Konstanten auf 32 Bit erweitert. Dies wird 
durch die +L-Compiler-Option erreicht. 

Die C-Support Funktionen der c32.1ib, cl32.1ib etc. wurden nun 
mit dieser +L-Option compiliert und können als Fehlerquelle bei 
Lattice-Aztec-Konvertierungen ausgeschlossen werden. 

Hier nun eine Liste aller Linker-Optionen: 

-OFilename 

Das ausführbare Programm wird unter dem hier angegebenen 
Namen abgespeichert. Wird diese Option nicht verwendet, erhält 
das ausführbare Programm den Namen des Objekt-Files ohne 
die Extension .o. 

-LFilename 

Mit dieser Option legen Sie die Linker-Librarys fest, die zum 
Objekt-File des Programms gelinkt werden sollen. 
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-FFilename 

Der Linker liest die Argumente aus dem hier angegebenen 
ASCII-File. Dies ist nützlich, wenn Sie dem Linker sehr viele 
Parameter übergeben wollen. 

-T 

Diese Option veranlaßt den Linker, die Linker-eigene Symbolta¬ 
belle als ASCII-File abzuspeichern. Der Name dieses ASCII-Files 
wird durch den Namen des Objekt-Files mit auf .sym geänderter 
Extension gebildet. Dieses ASCII-File enthält Informationen 
über das File - in welchem Segment der Code steht und in 
welchen Hunks (=Abschnitten) ausführbare Befehle, Systemva¬ 
riablen und Programmvariablen enthalten sind. Die Hunks wer¬ 
den durch die Label _Hx_org (org = origin) und _hx_end 

eingeschlossen, wobei für x die Jeweilige Hunk-Nummer einge¬ 
tragen wird. In Programmen, die nur aus einem Modul bestehen, 

werden die Programmvariablen zwischen _H2_org und 

_H2_end abgespeichert. Das Programm beginnt bei 

_H0_org. 

-W 

Diese Option veranlaßt den Linker, Informationen für den De¬ 
bugger db abzuspeichern. Diese Informationen sind die Namen 
der Label sowie die Offsets zum Programmbeginn, an der die 
Label stehen (siehe -T-Option). 

-V 

Es wird eine Hunk-Statistik ausgegeben. 

+0[i] 

Diese Option veranlaßt den Linker, das nachfolgende Objektmo¬ 
dul in das nächste bzw. in das angegebene Code-Segment zu 
schreiben. 

+C[cdb] 

Diese Option veranlaßt den Linker, dafür zu sorgen, daß das 
Code-Segment (+Cc), das Data-Segment (+Cd) oder beide Seg¬ 
mente (+Cb) des ausführbaren Programms in den Chip-Memory 
geladen werden. 
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■hFfcdbJ 

Diese Option veranlaßt den Linker, dafür zu sorgen, daß das 
Code-Segment (+Fc), das Data-Segment (+Cd) oder beide Seg¬ 
mente (+Fb) des ausführbaren Programms in den Fast-Memory 
geladen werden. 

+A 

Diese Option veranlaßt den Linker, jedes Objektmodul an einer 
Langwortadresse beginnen zu lassen. 

-C -ß 

Diese Optionen veranlassen den Linker, Informationen für den 
Source-Level-Debugger abzuspeichern (Extension: .dbg). 

+ß 

Diese Option veranlaßt den Linker, nicht mehr die Prozeduren 
der Objekt-Files, die gerade gelinkt werden, auszugeben. 

-M 

Der Linker beschwert sich nun, wenn Sie in einem Ihrer Module 
eine Funktion einer Linker.Library definieren. Ohne -M über¬ 
schreibt Ihre neue Prozedur die Linker-Library-Prozedur (siehe 
Stack-Overflow). 

+L 

Diese Option veranlaßt den Linker anzunehmen, daß die folgen¬ 
den Objektmodule "wahre" Amiga-Linker-Librarys sind. Auch 
der Versuch, die c32.1ib mit Hilfe dieser Option zu linken, 
brachte keinen Erfolg. 

+s, 

+SS, 

■hSSS 

Ohne Angabe von +s, +ss und +sss wird der gesamte Code des 
Programms in einen Hunk geschrieben. +s veranlaßt den Compi¬ 
ler, den ausführbaren Code eines jeden Objektmoduls und die in 
den Modulen benutzten Linker-Library-Routinen in separate 
Hunks zu schreiben. +ss bedeutet, daß der Code in einen Hunk 
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geschrieben wird, solange der Code die Größe von 8 KByte 
nicht übersteigt. Nach 8 KByte wird einer neuer Hunk benutzt. 
+SSS schließlich veranlaßt den Linker, für jedes Modul jeweils 
einen Hunk zu verwenden. Dabei sollten Sie beachten, daß Lin- 
ker-Librarys Zusammenschlüsse mehrerer Module sind und so 
jede benutzte Routine in einen Hunk geschrieben wird. 


2.4 Das Debuggen von Programmen 

Was tun, wenn trotz aller Vorsichtsmaßnahmen das Programm, 
das man mühevoll entwickelt hat, nicht so läuft, wie man es ei¬ 
gentlich wünscht oder sogar abstürzt? 

Hier gibt es - grobgesagt - zwei Vorgehensweisen: 

1. Man läßt sich mit Hilfe des printf()-Befehls Variablen-In- 
halte, Strings usw. ausgeben, und kontrolliert diese Werte. 

2. Man verwendet einen Debugger, mit dem man den Ablauf 
des Programms bestimmen und testen kann. 

Meistens ist es jedoch so, daß man eine Symbiose beider Vorge¬ 
hensweisen wählt, da entweder die Variablenüberprüfung mit 
Hilfe des Debuggers zu mühsam ist, oder andererseits bestimmte 
Zugriffe (vor allen Dingen Zugriffe mit Hilfe von Zeigern) 
nicht durch den printf()-Befehl sichtbar gemacht werden kön¬ 
nen. 

Betrachten wir einmal die Vorgehens weise mit Hilfe des 
printf()-Befehls. 

Angenommen, Ihr Programm besteht aus mehreren Funktionen. 
Um nun festzustellen, in welcher Funktion der Fehler ist, der 
zum Programmabsturz führt, können Sie als ersten Befehl immer 
printf(Name der Funktion\n); aufrufen. Meistens haben Sie die 
Möglichkeit, festzustellen, welche Routine zuletzt angesprungen 
wurde, die den Fehler erzeugt hat. 

Auch innerhalb von Schleifen kann man gut mit der printf()- 
Methode arbeiten. Wenn man sich z.B. nicht sicher ist, wieviele 
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Array-Elemente in einer Schleife initialisiert werden, kann man 
die Elementnummern bzw. den Inhalt der Schleifenvariablen 
ausgeben lassen. Ebenso kann man bei String-Manipulationen 
Vorgehen, wenn man nicht sicher ist, hinter welches Zeichen z.B. 
die String-Endemarke (der ASCII-Code 0 - ausgedrückt durch 
\000) gesetzt wird. 

Manchmal braucht man aber gar nicht soweit zu gehen, jede 
einzelne Routine in dieser Form zu kennzeichnen. Nach ein paar 
Monaten Programmierpraxis kann man sich auf seine Eingebun¬ 
gen verlassen und an der vermuteten Stelle nach dem Fehler 
suchen. Oder wenn man sich beim Programmieren an einer Stelle 
nicht ganz sicher war, kann man eben diese Stelle einer genauen 
Untersuchung unterziehen. 

Auch bestimmte Guru-Meditations können Ihre Vorahnungen 
bestätigen. Besonders die Trap-Codes der Guru-Medittion (siehe 
Tabelle 3.16) können wertvolle Hinweise geben: 

Error-Code 00000003 weist Sie auf einen Adressierungsfehler 
hin. Das bedeutet, daß bei einem Wort- oder Langwortzugriff 
auf eine ungerade Adresse zugegriffen wurde. Das kann Sie 
veranlassen, Ihre WORD- und LONG-Pointer noch einmal zu 
überprüfen. 

Der Fehlercode 00000004 (Illegaler Opcode) weist Sie darauf hin, 
daß bei der Benutzung von Librarys oder Devices ein Fehler 
beim Aufruf einer Funktion stattgefunden hat. Besonders bei 
den Devices, denen ein sogenannter Device-Block übergeben 
werden muß, kann solch ein Fehler auf treten, da in dem De¬ 
vice-Block die aufzurufenden Routinen enthalten sind. Tritt nun 
ein Fehler bei der Übergabe dieses Device-Blockes an eine 
Funktion auf, kann es sehr leicht passieren, daß eine Speicher¬ 
stelle angesprungen wird, die gar keinen ausführbaren Code ent¬ 
hält. 

Auch der Fehler 00000008 sollte Sie stutzig machen. Dieser 
Fehler tritt dann auf, wenn Maschinensprachebefehle ausgeführt 
werden sollen, die nur im Supervisor-Modus aufgerufen werden 
dürfen. Dieser Fehler kann insbesondere bei der Manipulation 



112 


Das große C-Buch zum Amiga 


von Tasks auftreten. Wenn man hier nicht sehr vorsichtig ist, 
kann es leicht zu solchen Systemabstürzen kommen. 

Neben diesen hausgemachten Debugging-Tips stehen Ihnen aber 
vor allem beim Aztec-Compiler zwei sehr kraftvolle Debugger 
(Entwanzer) zu Verfügung: 


2.4.1 DerAztec-DB 

Um den Aztec-DB in Verbindung mit Ihrem Programm benut¬ 
zen zu können, sollten Sie das Programm mit Hilfe der Option - 
w linken. Diese Option sorgt dafür, daß die einzelnen Symbole 
des Programms (die Namen der globalen Variablen und aller 
Funktionen) auch abgespeichert werden. Dies erhöht die Lesbar¬ 
keit des Programms ungemein, denn der dargestellte Maschi¬ 
nencode wirkt doch sehr konfus, wenn man nicht ein paar An¬ 
haltspunkte wie Variablen und Funktionen hat. Es ist zwar mög¬ 
lich, ein Programm, daß nicht mit der Option -w gelinkt oder 
gar vollkommen in Assembler geschrieben wurde, zu debuggen. 
Allerdings muß man hier sehr viel Geduld haben, sich viele No¬ 
tizen machen, um nicht den Überblick zu verlieren. 

Doch kommen wir dazu, wie man den Debugger DB verwendet. 
(Auch für Lattice-Benutzer kann es evt. recht interessant sein zu 
wissen, wie man den DB verwendet, da damit auch ihre Pro¬ 
gramme untersucht werden können. Allerdings muß man hier 
auf die Symbol-Tabellen verzichten.) 

Zunächst einmal muß der DB auf gerufen werden. Dies geschieht 
einfach durch Eingabe von "DB" <Return> auf der CLI-Ebene. 
Der Debugger wird geladen, gestartet und ist sofort einsatzbe¬ 
reit. Besonders die Version 3.6 des Debuggers ist sehr komforta¬ 
bel. Man hat hier nämlich die Möglichkeit, im File SYS:s/.dbinit 
die Befehlssequenz anzugeben, die direkt nach dem Aufruf des 
Debuggers ausgeführt werden soll. (Der DB befindet sich übri¬ 
gens auf der Diskette SYS2: im Verzeichnis bin). 

Normalerweise steht im File .dbinit der Befehl al. Dieser Befehl 
bedeutet: "Load Task". Es wird also auf das nächste Programm 
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gewartet, das gestartet wird. Um also Ihr Programm zu debug- 
gen, brauchen Sie dieses nur wie gewohnt zu starten. Daraus er¬ 
klärt sich auch, daß der Debugger sofort nach Eingabe des al- 
Kommandos zur CLI-Ebene zurückkehrt, bzw. das eigene Fen¬ 
ster ganz in den Hintergrund setzt. 

Sie können nun im CLI-Fenster Ihr zu debuggendes Programm 
starten. Doch Vorsicht! Achten Sie darauf, daß das CLI-Fenster 
auch tatsächlich aktiviert ist. Ist dies nämlich nicht der Fall, 
werden alle Tastatureingaben an den Debugger gesendet, der 
diese zunächst als Wunsch zur Unterbrechung des al-Befehls und 
weiterhin als neuen Befehl interpretiert! 

Doch betrachten wir, was nach dem Start des zu debuggenden 
Programms geschieht: 

Zunächst erscheint wieder das Fenster des Debuggers im Vor¬ 
dergrund. In das Fenster wird die Meldung "Loading Syms..." 
geschrieben. Dies weist Sie darauf hin, daß versucht wird, das 
Programm sowie die durch die Linker-Option -w erzeugte Sym¬ 
boltabelle zu laden. Wenn solch eine Tabelle nicht geladen wer¬ 
den kann, weil sie für das zu debuggende Programm nicht er¬ 
zeugt wurde, erscheint eine diesbezügliche Meldung. 

Doch betrachten wir, was passiert, wenn Programm samt Sym¬ 
boltabelle geladen wurde. Zunächst wird der erste Befehl des 
Programms dargestellt. Achtung! Bei C-Programmen ist mit dem 
ersten Befehl des Programms nicht der Befehl gemeint, der der 
erste der main()-Funktion ist. Der erste Befehl eines C-Pro- 
gramms sieht wie folgt aus: 

_H0_org jmp .begin 

Normalerweise wird der Befehl jmp .begin zu Beginn eines je¬ 
den Moduls erzeugt. Allerdings wird nur derjenige jmp.begin- 
Befehl ausgeführt, der im ersten gelinkten Modul steht. Um also 
Speicherplatz zu sparen, können Sie bei mehreren Programmmo¬ 
dulen die Erzeugung von jmp .begin bei jedem Modul unter¬ 
binden (siehe auch Compiler- und Assembler-Optionen). 
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Doch was bedeutet dieser Befehl? Dieser Befehl springt den 
Startup-Code eines jeden C-Programms an. Dieser befindet sich 
in der Linker-Library c.lib (Aztec) und dient dazu, die Exec- 
und Dos-Library für das C-Programm nutzbar zu machen und 
die Kommando-Parameter für die Routine main() aufzuarbeiten. 

Wenn sich jemand für diesen Startup-Code interessiert, kann er 
ihn mit dem Kommando s <Return> single-steppen lassen. Mit s 
wird jeder einzelne Befehl des Programms abgearbeitet, und 
nach der Abarbeitung werden die Registerinhalte ausgegeben 
(inklusive Programm-Counter (Pc), Status-Register (Sr) und den 
Condition-Flags (x - Extension- (Erweiterungs)-Flag, n - Nega¬ 
tiv-Flag, z - Zero (Null) - Flag, v - Overflow- (Überlaufs)- 
Flag, c - Carry- (Übertrags)-Flag). Nachdem die Registerinhalte 
angezeigt wurden, wird der nächste abzuarbeitende Befehl an¬ 
gezeigt. 

Wenn beim Single-Steppen auf den Aufruf einer Routine ge¬ 
stoßen wird, deren Funktion man kennt, braucht man nicht je¬ 
den einzelnen Befehl dieser Routine durchzugehen. Man kann 
durch das t- (Trace)-Kommando dafür sorgen, daß diese Rou¬ 
tine ausgeführt wird. Das funktioniert aber nur bei JSRs. Wenn 
also der nächste Befehl z.B. jsr _OpenWindow ist, können Sie 
durch t <Return> veranlassen, daß das Window geöffnet wird. So 
brauchen Sie nicht jeden einzelnen Befehl dieser Routine mit s 
ausführen zu lassen. Erstens werden Sie wahrscheinlich sowieso 
nicht so wahnsinnig viel davon verstehen, was bei der Ausfüh¬ 
rung solch eines Befehls vonstatten geht, und zweitens ist das 
Single-Steppen eines solchen Befehls meist sehr zeitaufwendig. 
Diese Zeit sollten Sie lieber darauf verwenden, Ihre eigenen 
Routinen zu debuggen. Außerdem kann man davon ausgehen, 
daß die Systembefehle fehlerfrei funktionieren. (Es sei denn, 
daß man bei der Übergabe von Parametern Unsinn gemacht hat. 
Dies muß man aber im Vorfeld des Aufrufs dieser Routine er¬ 
kennen und nicht während der Abarbeitung dieses Befehls.) 

Sicher werden Sie auch festgestellt haben, daß das Single-Step¬ 
pen des Startup-Codes sehr zeitaufwendig ist und eigentlich 
nicht viel bringt. Wie gelangt man nun an die Stelle eines Pro¬ 
gramms, die wirklich von Interesse ist? Hierbei helfen uns söge- 
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nannte Break-Points (Unterbrechungsstellen), an denen ein Pro¬ 
gramm unterbrochen wird. 

Mit Hilfe eines solchen Break-Points kann man sehr einfach zur 
Funktion main() gelangen, die ja der eigentliche Ausgangspunkt 
eines jeden C-Programms ist. 

Mit bs _main setzt man einen Break-Point auf die Routine 
_main(). (Sicher ist Ihnen der Unterstreicher aufgefallen, der 
vor jede Routine gesetzt wurde. Bei der Übersetzung eines C- 
Programms in Maschinencode wird dafür gesorgt, daß vor jede 
Routine und globale Variable ein Unterstreicher gestellt wird.) 
Wenn man nun den Debugger mit Hilfe des g-Kommandos ver¬ 
anlaßt, das Programm auszuführen, wird zunächst der Startup- 
Code abgearbeitet. Wenn dann die Routine _main abgearbeitet 
werden soll, stellt der Debugger fest, daß hier ein Break-Point 
gesetzt wurde und unterbricht den Ablauf des Programms. Sie 
haben nun die Möglichkiet, mit Hilfe von s und t durch den 
Rest des Programms zu wandern. 

Die Kommandos al (Load Task), s (Single-Step), t (Trace), g (Go 
= Programm unter Kontrolle des Debuggers ablaufen lassen) und 
bs (Break-Point-Setting) reichen also vollkommen aus, um ein 
Programm zu debuggen. Wenn das Programm beim Debuggen 
abstürzt, sehen Sie den Befehl, der das Programm zum Absturz 
gebracht hat. Meistens stürzt ein Programm während des Debug¬ 
gings aber nicht in gewohnter Weise mit einer Guru-Meditation 
ab. Da der Debugger vollkommene Kontrolle über Ihr Programm 
und das System hat, ist er in der Lage, Sie mit einer Debugger- 
Meldung auf einen aufgetretenen Fehler hinzuweisen. Aber lei¬ 
der ist auch der Debugger nicht immer in der Lage, Sy¬ 
stemabstürze abzufangen. Insbesondere bei Interrupt- und Task- 
Umschaltungsvorgängen kann es passieren, daß selbst der De¬ 
bugger solche Fehler nicht mehr abarbeiten kann. Dies liegt zum 
großen Teil daran, daß der Debugger sehr intensiv mit Inter¬ 
rupts und Task-Manipulationen arbeitet. 

Neben den oben aufgezählten einfachen Kommandos des Debug¬ 
gers kann dieser aber wesentlich mehr. Da diese Kommandos für 
den Hausgebrauch kaum gebraucht werden, wollen wir diese 
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hier auflisten und von Fall zu Fall nur etwas näher auf diese 
Befehle eingehen. 

Zunächst einmal ein Überblick über die Syntax der Parameter: 

Wenn bei einem Befehl der Ausdruck "AUSDR" als Parameter 
hat, so kann "AUSDR" folgendes Aussehen haben: 

AUSDR = TERM [binärer Operator-Term], 

wobei die binären Operatoren folgendes Format haben: 

Binäre Operatoren: 


+ Addition 
- Subtraktion 
* Multiplikation 
/ Division 
% Modulo-Devision 
& Bit-weises UND 
I Bit-weises ODER (inklusiv) 
Bit-weises ODER (exklusiv) 


TERM hat folgendes Format: 


TERM: 

REGISTER, 

KONSTANTE, 

-TERM, 

ADDR, (Adresse) 

♦ADDR, (Inhalt der Adresse) 

(AUSDR) 

REGISTER: 

Der Parameter REGISTER hat folgendes Format: AO, Al, DO, 
Dl, etc. Weiterhin sind folgende Register bekannt: PC und SP 
(Synonym für A7 (Stackpointer)). 

KONSTANTE: 

Dieser Parameter ist eine hexadezimale, binäre, oktale oder de¬ 
zimale Konstante: 
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Oxabcd (hexadezimal) 

O0I247 (oktal) 

ObOIIO (binär) 

123. (dezimal) 

Falls keiner der Operatoren Ox, Oo, Ob oder . (Dezimalpunkt) 
verwendet wird, so wird die Konstante bezüglich der aktuellen 
Basis (siehe n-Kommando) interpretiert. 

ADDR 

Dieser Parameter legt eine Adresse fest. Dabei sind sowohl 
_main, 0x1264789 und _main+le2 gültige Adressen im Sinne 
des DB. 

*ADDR 

Mit Hilfe dieses Parameters erhalten Sie den Inhalt des Long- 
words, auf das ADDR zeigt. Es ist auch möglich, den Inhalt der 
Speicherstellen zu erfahren, auf die ein Register zeigt: *A7 (In¬ 
halt des obersten Stack-Langwortes). Beachten Sie, daß Klam¬ 
mern gesetzt werden müssen bei Ausdrücken wie '•‘SP+ö, die 
*(SP+6) bedeuten sollen. 


Dieser Parameter enthält die Anfangsadresse für ähnliche Kom¬ 
mandos. Mit db 0x200, 20. ist es z.B. möglich, die 20 Bytes, die 
ab Adresse 0x200 stehen, auszugeben. Wenn Sie nun den Punkt 
in Verbindung mit dem dw-Kommando verwenden, werden ab 
Adresse 0x200 die 20 folgenden WORDs ausgegeben. Beachten 
Sie, daß dieser Punkt nicht mit dem Dezimalpunkt zu verwech¬ 
seln ist und für verschied^ene Befehle verschiedene Bedeutungen 
haben kann (siehe db und dw). 

@[Name einer Funktion] 

Dieser Parameter ist insbesondere in Verbindung mit dem g- 
Kommando (Go) interessant. Folgender Aufruf sorgt dafür, daß 
ans Ende der gerade aktuellen Funktion ein Break-Point gesetzt 
wird und daß beim Erreichen dieses Break-Points das Programm 
unterbrochen wird: 
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g @ 

Wenn Sie wollen, daß das Programm am Ende einer bestimmten 
Funktion unterbrochen wird, müssen Sie den @-Parameter wie 
folgt benutzen: 

g @Name_Der_Funktion 

Wenn bei der Ausführung des Go-Kommandos das Ende der 
spezifizierten Funktion erreicht wird, wird das Programm unter¬ 
brochen. 

Neben dem AUSDRUCK existieren noch BEREICHe und 
CMDLISTEN (Kommandolisten): 

BEREICH: 

AODR,ZÄHLER 
ADDR>AD0R 
ADDR 
.ZÄHLER 

Bei BEREICHen wird wie folgt vorgegangen: Wird der BE¬ 
REICH durch ADDR,ZÄHLER definiert, so werden z.B. ab der 
angegebenen Adresse ZÄHLER-Bytes, Words oder Longwords 
ausgegeben. Bei ADDR>ADDR werden - je nach auf gerufenem 
Befehl - die zwischen diesen Adressen liegenden Bytes, Words 
oder Longwords ausgegeben. 

Wird nur die ADDRESSE angegeben, so wird die vorher festge¬ 
legte Anzahl auszugebender Bytes etc. verwendet. 

Bei alleiniger Angabe eines Zählers wird die zuletzt erreichte 
Adresse (z.B. ADDR+ZÄHLER des vorigen Befehls) verwendet. 

Fehlt diese Angabe, so wird die zuletzt erreichte Adresse und 
der alte Zähler verwendet. Beachten Sie, daß der Zähler je nach 
verwendetem Befehl unterschiedlich interpretiert werden kann. 
Er kann z.B. die Anzahl der auszugebenden Bytes bestimmen 
oder aber die Anzahl der auszugebenden Linien eines As¬ 
sembler-Dumps. 

CMDLISTEN sind Kommandolisten und werden wie folgt defi¬ 
niert: 
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CMDLISTE: Kommando [; Kommando ...] 

Die Kommandoliste besteht also aus aneinandergereihten Kom¬ 
mandos, die durch ein Semikolon getrennt werden. Diese sind: 

add 

Alle im System vorhandenen Devices anzeigen. 
adi 

Alle im System vorhandenen Interrupts anzeigen. 
adl 

Alle im System vorhandenen Librarys anzeigen. 
adp 

Alle im System vorhandenen und mit einem Namen versehenen 
Message-Ports auflisten. 

adr 

Alle im System enthaltenen Resources anzeigen. 
ai 

Informationen über einen Task anzeigen. Wenn ein Programm 
debugged werden soll, werden nach ai die Informationen über 
den Programmtask ausgegebn. Ist kein Programm geladen, kön¬ 
nen Sie durch Eingabe einer Nummer einen Task auswählen, 
dessen Informationen Sie betrachten wollen. Der DB informiert 
Sie natürlich auch darüber, welche Nummer zu welchem Task 
gehört. 

ak 

Dieser Befehl versucht, die Routine _abort oder exit() auf¬ 
zurufen, um das Programm, das gerade debugged wird, aus dem 
Speicher zu entfernen. Wenn das Programm auf diese Art und 
Weise nicht entfernt werden kann, muß das System neugebootet 
werden. Es gibt allerdings noch die Möglichkeit, mit Hilfe des 
Setzens des Programm-Counters das Programm zu verlassen: 
rPC=_exit und g. 
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al, aL 

Lade das Programm, das als nächstes vom CLI oder der Work- 
bench aus gestartet wird, in den Debugger. Bei al wird dabei die 
Symboltabelle mit geladen, während bei aL auf die Sym¬ 
boltabelle verzichtet wird. 

an, aN 

Erzeuge ein neues Debugger-Window. Bei an wird die Symbol¬ 
tabelle des Hauptfensters verwendet, während aN eine eigene 
Symboltabelle enthält, an läßt sich also gut dazu verwenden, 
einen Untertask, der vom zu debuggenden Programm erzeugt 
wird, zu debuggen, währen aN für ein ganz neues Programm 
benutzt werden kann. 

am 

Zeige verfügbaren Speicher an. 
ap, aP 

Diese Funktion ist sehr interessant. Sie dient dazu, abgestürzte 
Programme zu debuggen. Wenn also der DB schon gestartet 
wurde oder aus einem anderen CLI noch auf gerufen werden 
kann, ist es möglich, herauszufinden, wo die Guru-Meditation 
erzeugt wurde. 

Dazu brauchen Sie nur ap (mit Symboltabelle, die der DB 
nachzuladen versucht) bzw. aP (ohne Symboltabelle) aufzurufen. 
Danach brauchen Sie nur den "Finish all Disk-Activities..."-Re- 
quester zu "canceln" und können das Programm, das zum Sy¬ 
stemabsturz geführt hat, debuggen. Dies funktioniert allerdings 
nur dann, wenn alle Systemstrukturen erhalten worden sind. 
Wenn also bestimmte Speicherbereiche Überschrieben wurden 
und so wichtige Informationen fehlen, kann auch das ap-Kom- 
mando nichts bewirken. 

aq 

Schließe sofort alle DB-Fenster und beende die DB-Sitzung. 
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ar 

Wenn ein Task zum Debuggen auserwählt wurde, wird dieser 
solange angehalten, bis der Benutzer s, t oder g verwendet. Der 
Debugger behält aber immer die Kontrolle über diesen Task, 
solange der Task nicht beendet wurde. Mit ar ist es möglich, 
einen zum Debuggen ausgewählten Task wieder aus den Klauen 
des DB zu entfernen (Allow Task to resume). 

as, aS 

Mit diesem Kommando können Sie einen Systemtask zum De¬ 
buggen auswählen. Nach dem Aufruf dieses Kommandos werden 
Sie nach der Nummer des zu debuggenden Tasks gefragt, (as 
verwendet die Symboltabelle, aS nicht.) 

at 

Nach diesem Kommando werden alle Systemtasks, sowie deren 
Identifikationsnummern für as und ap, angezeigt. 

bb 

bw 

bl 

bb ADDR [== [AUSDR]] 
bb ADDR [!= [AUSDR]] 
bw ADDR [== [AUSDR]] 
bw ADDR [!= [AUSDR]] 
bl ADDR [== [AUSDR]] 
bl ADDR [!= [AUSDR]] 

Mit Hilfe dieser Kommandos ist es möglich, sogenannte Me- 
mory-Break-Points zu setzen. Mit Hilfe dieser Memory-Break- 
Points kann man eine Programmunterbrechung veranlassen, so¬ 
bald der Wert der Speicherstelle, der durch ADDR bestimmt 
wird, vom alten Wert abweicht (bb ADDR) bzw. gleich oder un¬ 
gleich dem angegebenen Wert ist (bb != 0, oder bb == 0). Je 
nach Befehl bestimmt ADDR die Adresse eines Bytes, Words 
oder Longwords. 
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bc ADDR 
bC 

Diese Kommandos erlauben es, alle Break-Points zu löschen 
(bC). Mit bc ADDR wird nur der angegebene Break-Point ge¬ 
löscht. 

bd 

Dieser Befehl listet alle Break-Points auf. Dabei wird - wenn 
möglich - der Symbolname des Breakpoints angegeben, die An¬ 
zahl der "Break-Point-Treffer", die Anzahl der "Break-Point- 
Ignorier-Rate" sowie der Befehl, der bei Antreffen eines Break- 
Points ausgeführt werden soll: 

adress hits skip command 

_main 0 0 

^GetDir 1 3 db FIB+20.,30. 

Diese Liste sagt aus, daß zwei Break-Points existieren. Und zwar 
am Anfang der Routine _main und _GetDir. 

Die Angaben bei hits sagen aus, wie oft schon auf den jeweili¬ 
gen Break-Point getroffen wurde, skip gibt an, wieviele Break- 
Point-Treffer lang nichts geschehen soll. _GetDir ist schon ein¬ 
mal angesprungen worden, aber erst nach dem 4ten Aufruf die¬ 
ser Funktion wird tatsächlich eine Programmunterbrechung aus¬ 
gelöst, wobei dann der unter command stehende Befehl aus¬ 
geführt wird. 

bh [BEREICH] 

Mit Hilfe dieses Befehls ist es möglich, eine Veränderung inner¬ 
halb des durch BEREICH festgelegten Speicherabschnittes fest¬ 
zulegen. Dazu wird über den BEREICH eine Checksumme ge¬ 
bildet, die nach jedem ausgeführten Befehl neuberechnet, und 
mit der Original-Checksumme verglichen wird. Beachten Sie,so 
daß durch Break-Point-Kommandos (insbesondere durch bh) die 
Abarbeitungszeit des Programms drastisch verlängert werden 
kann. 
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bq 

Dieses Kommando erlaubt Ihnen, die Checksummenberechnung- 
und -Überprüfung des Bereichs von Adresse 0 bis Adresse 255 
an- bzw. auszuschalten. Nach dem Start von DB ist diese Über¬ 
prüfung angeschaltet. Immer dann, wenn eine Veränderung in 
den untersten 256 Bytes festgestellt wird, wird die Meldung 
"Low memory Checksum different !!!" ausgegeben. 

Wenn Sie diese Überprüfung abschalten, ist der Single-Step 
(Kommando: s) ein wenig schneller (Quick-Step). 

br [ADDR ] 

Mit Hilfe dieses Kommandos wird der hits-Zähler des angege¬ 
benen (br ADDR), oder aller Break-Points (br) auf 0 gesetzt. 

/#; bs ADDR [;CMDUSTE] 

Bei Verwendung dieses Kommandos wird ein Break-Point fest¬ 
gelegt. Dabei wird die durch das Zeichen # repräsentierte Zahl 
der SKIP-Zähler angegeben. CMDLISTE enthält die/den Be¬ 
fehle), die nach dem Erreichen des Break-Points ausgeführt 
werden sollen. Beispiel: 

3 bs _GetDir db _FIB+20.,20. 


bt, bT 

Diese beiden Kommandos versetzen Sie in die Lage, den Trace- 
(bt) bzw. Back-Trace-Modus (bT) an- bzw. auszuschalten. 

Nach bt werden alle Routinen, die angesprungen werden, sowie 
die Übergabeparameter (als WORDS) angegeben. 

Nach bT wird der jewelige Name der Routine, die verlassen 
wird, ausgegeben. 

bu [ADDR] 

Dieses Kommando veranlaßt den DB dazu, nach dem Auftreten 
eines Break-Points die hier angegebene Routine anzuspringen. 
Die Routine, die aufgerufen wird, muß eine C-Routine sein. 
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Das heißt, daß die C-spezifischen Register gerettet werden 
müssen. 

Der Routine wird ein Langwort-Array übergeben, das folgende 
Werte enthält: 

Die Werte von D0-D7. 

Die Werte von A0-A7. 

Den Wert des Status-Registers. 

Den Wert des Programm-Counters. 

bu 0 sorgt dafür, daß die Break-Points unbeachtet bleiben. 

cs 

Dieses Kommando sorgt dafür, daß die Symboltabelle gelöscht 
wird. 

db [BEREICH] 
dw [BEREICH] 
dl [BEREICH] 
d 

Diese Kommandos geben den Bereich in Bytes (db), Words (dw) 
oder Longs (dl) aus. Bei der Angabe des Bereiches ist die Start- 
Adresse optional. Geben Sie nur die Endadresse oder einen 
Zählwert an, so wird der Speicher ab der letzten dargestellten 
Speicherstelle ausgegeben. Wenn Sie nur d angeben, wird der 
Bereich im Format des vorigen Befehls (Byte, Word, oder Long) 
ausgegeben. 

de 

Alle Code-Symbole (Funktionsnamen) anzeigen lassen. 
dd 

Alle Daten-Symbole (Variablen) ausgegeben. 
dg 

Dieses Kommando gibt alle Symbole der Symboltabelle mit der 
jeweiligen Adresse aus. 
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ds 

Mit Hilfe dieses Kommandos können Sie zurückverfolgen, wel¬ 
che Routinen mit welchen Parametern auf gerufen wurden. Aus¬ 
gehend von der aktuellen Funktion wird die Routine, die diese 
Routine auf gerufen hatte, deren auf rufende Routine usw. bis 
zum Aufruf von _main() inklusive Parameter (Word-Format) 
ausgegeben (Backtracking). 

[*] 8 [@ Funktionsname] [ADDR] [ ;CMDLISTE] 
f#J G f@ Funktionsname] [ADDR] [;CMDLISTE] 

Diese Kommandos führen das zu debuggende Programm aus. Bei 
g werden die Break-Points, die durch bs gesetzt wurden, be¬ 
rücksichtigt, während G nur den Break-Point berücksichtigt, der 
beim Aufruf dieses Kommandos spezifiziert wird. 

# gibt den "Skip-Count" des Break-Points an. ADDR ist die 
Adresse, wo der Break-Point gesetzt werden soll. Die CMDLI- 
STE schließlich bestimmt, welche Kommandos nach dem Auf¬ 
treten eines Break-Points ausgeführt werden sollen. 

Funktionsname" bestimmt den Namen der Funktion, bei 
dessen Ende ein Break ausgeführt werden soll. 

Is Programmname 

Mit Hilfe dieses Kommandos kann die Symboltabelle eines Pro¬ 
gramms erneut geladen werden. Dies ist dann recht nützlich, 
wenn die alte Symboltabelle verändert wurde. Symbole, die mit v 
in die Symboltabelle geschrieben wurden, bleiben erhalten. 

ma AU SDR 

Dieses Kommando reserviert Speicherplätze. EXPR gibt dabei 
die Anzahl der zu belegenden Bytes an. Ihnen wird durch Aus¬ 
gabe der Anfangsadresse mitgeteilt, wo der von ihnen belegte 
Speicher zu finden ist. Beim Verlassen des DB wird dieser 
Speicher automatisch freigegeben. 
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mb ADDR AUSDRl [AUSDR2 ..] 
mw ADDR AUSDRl [AUSDR2 ..] 
ml ADDR AUSDRl [AUSDR2 ..] 

Mit Hilfe dieser Befehle können Sie Speicherstellen verändern. 
Dazu geben Sie die Anfangsadresse des zu verändernden 
Speicherbereichs an (ADDR) und bestimmen durch AUSDRl 
(AUSDR2 ...), welche Werte in diesen Speicherbereich geschrie¬ 
ben werden sollen. Mit mb werden Bytes, mit mw Words und 
mit ml Longwords geschrieben. 

mc BEREICH = ADDR 

Mit Hilfe dieses Kommandos können Sie einen Bereich mit den 
ab ADDR stehenden Bytes vergleichen. Es werden jeweils die 
Unterschiede ausgegeben (ADDRl != ADDR2). 

mf BEREICH = AU SDR 

Dieses Kommando füllt den angegebenen BEREICH mit dem in 
AUSDR spezifizierten Wert (Byte). 

mm BEREICH = ADDR 

Mit Hilfe dieses Kommandos können Sie den BEREICH an die 
angegebene Adresse kopieren 

ms BEREICH = AUSDRl [AUSDR2 ...] 

Mit Hilfe dieses Kommandos kann ein Bereich nach der angege¬ 
ben Byte-Folge (AUSDRl...) durchsucht werden. Immer dann, 
wenn die Byte-Folge gefunden wurde, wird die Anfangsadresse 
äusgegeben. 

nX 

Berechnungsbasis für alle Berechnungen und Angaben verändern; 

nb: binär 
nd: dezimal 
nx: hexadezimal 
no: oktal 
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Q 

Mit Hilfe dieses Kommandos wird der DB verlassen. Der zu de- 
buggende Task wird freigegeben, alle DB-Fenster werden ge¬ 
schlossen. 

r [reg=AUSDR] 

Alle Registerinhalte (inklusive SR und PC) werden ausgegeben. 
Ist außerdem ein 68881-Mathemathik-Co-Prozessor eingebaut, 
werden auch dessen Register ausgegeben (Aufruf ohne Parame¬ 
ter). Mit Hilfe des r-Kommandos ist es auch möglich, Register¬ 
inhalte zu verändern (Beispiel: rPC = _exit). 

[#] s [:CMDUSTE] 

[*] S [:CMDUSTE] 

[#] t [.CMDLISTE] 

[*] T [;CMDUSTE] 

Diese Kommandos dienen zum Single-Steppen durch ein zu de- 
buggendes Programm, s führt den nächsten Befehl aus und gibt 
im Anschluß daran alle Registerinhalte aus. Bei S wird auch der 
nächste Befehl ausgeführt - allerdings wird hier auf die Ausgabe 
der Registerinhalte verzichtet. 

Nach gleichem Schema arbeiten die Kommandos t- und T. Al¬ 
lerdings wird hier eine ganze Routine - aufgerufen durch JST - 
abgearbeitet. Trifft man also innerhalb eines Programms auf 
einen JSR-Befehl, so gelangt man nach t bzw. T an den Befehl 
nach der Ausführung der Unterroutine. 

# gibt die Anzahl der Aufrufe von s, S, t, T an, die getätigt 
werden sollen. 

u [BEREICH] 

U [BEREICH] 

Mit Hilfe dieser Kommandos wird der angegebene Bereich di- 
sassembliert. Bei u werden dazu die Symbole verwendet, wäh¬ 
rend U mit absoluten Adressen arbeitet. 
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V SYMBOL = AUSDR 

V SYMBOL = AUSDR 

Diese beiden Kommandos erzeugen ein neues Symbol (v) bzw. 
verändern ein bestehendes (V). SYMBOL ist hierbei eine Zei¬ 
chenkette. 

Symbole, die mit v erzeugt werden, sind Code-Symbole (siehe 
de). 

xmc 

xm = CMDLISTE 

X? 

Mit Hilfe dieses Befehls können Sie Macros definieren. Dazu 
brauchen Sie nach x nur einen Buchstaben anzugeben und in der 
CMDLISTE zu bestimmen, welche Befehle ausgeführt werden 
sollen. 

Mit x(Buchstabe) wird das definierte Macro aufgerufen. Mit x? 
können Sie sich alle definierten Macros ausgeben lassen. Auf¬ 
grund der Tatsache, daß Sie nur einen Buchstaben nach x ange¬ 
ben können, können Sie maximal 26 Macros definieren. 

= AUSDR 

Mit Hilfe dieses Kommandos können Sie einen Ausdruck ausge- 


ben lassen. = 

1+2 erzeugt z.B: 


0x00000003 +3 3 

03 XII 

3 

1 

1 

hex 

1 1 

1 1 

signed dez 
dez 

1 1 

1 1 

okt bin 

1 1 

1 1 

ASCII String 

< File 

> File 

>> File 




Ein- und Ausgaben umlenken: 
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< File sorgt dafür, daß die Eingaben nicht mehr von der Ta¬ 
statur, sondern aus dem angegebenen File erfolgen. Dies ge¬ 
schieht solange, bis das File vollständig gelesen wurde. 

> File sorgt dafür, daß alle Ausgaben (Registerinhalte, etc.) in 
das angegebene File geschrieben werden. Dies geschieht solange, 
bis entweder ein neues Ausgabe-File festgelegt oder nur > auf¬ 
gerufen wird. Während der Ausgabe auf ein File wird auch das 
Window wie gewohnt verwendet. 

» File sorgt dafür, daß nur Kommandos in das angegebene File 
geschrieben werden. Dies ist z.B. dann recht nützlich, wenn der 
Debugging-Vorgang sehr kompliziert ist und häufig wiederholt 
werden muß (siehe: < File). Diese Option ist zu vergleichen mit 
dem Spielstand-Speichern bei einem Adventure - nicht allein 
deshalb, weil das Debuggen zu einem aufregenden und ner¬ 
venaufreibenden Abenteuer werden kann). 

? 

Dieses Kommandos gibt eine Übersicht über alle DB-Komman- 
dos aus. 


2.4.2 Der Aztec-Source-Level-Debugger 

Neben dem DB wird von der Firma Aztzec ein weiterer Debug¬ 
ger vertrieben. (Er ist nicht Bestandteil des Compilerpakets und 
muß gesondert erworben werden.) Dieser Debugger ist ein Mei¬ 
sterwerk der Programmierkunst. Mit ihm ist es nämlich möglich, 
C-Programme auf C-Source-Ebene (daher der Name Source-Le- 
vel-Debugger) zu debuggen. Das bedeutet, daß Sie jeden einzel¬ 
nen C-Befehl Ihres Programms debuggen können. Sie debuggen 
also nicht den Maschinencode, den der Compiler erzeugt, son¬ 
dern die einzelnen C-Befehle. Man könnte den Source-Level- 
Debugger mit einem C-Interpreter vergleichen. 

Wie benutzt man diesen Debugger nun? Zunächst muß auch hier 
dafür gesorgt werden, daß das C-Programm in einem bestimm¬ 
ten Format vorliegt. Dazu muß das Programm mit der Option -n 
compiliert werden. Hiermit werden dem Linker Informationen 



130 


Das große C-Buch zum Amiga 


bereitgestellt, um ein .dbg-File zu erzeugen, daß die vom 
Source-Level-Debugger benötigten Informationen enthält (Sym¬ 
bol-Tabelle). 

Um den Linker zu veranlassen, daß solch ein .dbg-File erzeugt 
wird, muß beim Linken die Option -g verwendet werden. Zu 
beachten ist, daß die Option -g vor der Angabe aller zu linken¬ 
den Module angegeben wird, damit alle Symbole (Variablen und 
Strukturen) in diesem .dbg-File enthalten sind: 

cc Programm -n 
ln -q Programm -Ic 

Kommen wir nun zum Aufruf des Debuggers. Auf gerufen wird 
der SDB nach folgendem Format: 

SDB [Optionen] [Programm [argv[1] argv[2] ...]] 

Sie können dem SDB also direkt beim Aufruf das zu debuggende 
Programm (inklusive Kommando-Parameter) übergeben. Weiter¬ 
hin können einige Optionen angegeben werden: 


SDB-Optionen 

-a 

Normalerweise wird der SDB im C-Modus benutzt. Wenn Sie 
allerdings diese Option verwenden, arbeitet der SDB im As¬ 
sembler-Modus - also so wie der DB. 

-w 

Normalerweise verwendet der SDB eigene Windows, um das zu 
debuggende Programm, Fehlermeldungen usw. darzustellen. 
Wenn Sie allerdings die Option -w verwenden, wird das CLI- 
Fenster als Ausgabefenster verwendet. (Diese Option ist recht 
nützlich, wenn das zu debuggende Programih sehr umfangreich 
ist, und mit dem Speicher gehaushaltet werden muß.) 

-p[ Promptstring ] 

Wenn Sie die Option -w verwenden, haben Sie mit Hilfe dieser 
Option die Möglichkeit, das Prompt nach Ihren Wünschen zu 
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gestalten. Wenn Sie die Option -p nicht verwenden, wird das 
Prompt sdb? verwendet. Wenn Sie nicht die Option -w verwen¬ 
den, wird als Promt CMD? ausgegeben. 


-e 

Der SDB nutzt 3 verschiedene Darteilungsbereiche innerhalb sei¬ 
nes Fensters. Der oberste Bereich wird zur Darstellung des C- 
Programms benutzt. Der mittlere Bereich stellt die Eingabezeile 
dar, in der Ihre Kommandos angegeben werden. Der unterste 
Bereich wird zur Ausgabe von Daten verwendet (Registerinhalte, 
Variableninhalte, Fehlermeldungen, Assemblerlistings usw.). 
Beim Aufruf des Debuggers werden die Kommandos nur in der 
Kommandozeile dargestellt. Wenn Sie den SDB aber mit dieser 
Option auf rufen, werden die Kommandos außerdem noch in 
dem unteren Datenbereich angezeigt. Dies ist dann recht nütz¬ 
lich, wenn Sie alle Ausgaben in ein File umlenken, um später 
nicht den Überblick darüber zu verlieren, welche Ausgabe durch 
welchen Befehl hervorgerufen wurde. 

-mFILENAME 

Mit Hilfe dieser Option werden alle Eingaben aus dem angege¬ 
benen File getätigt. Dies ist z.B. dann sehr nützlich, wenn immer 
einige Schritte ausgeführt werden müssen, bis man an eine feh¬ 
lerhafte Programmstelle gelangt. 

-sPFAD 

Der SDB geht davon aus, daß sich das zu debuggende Programm 
im aktuellen Verzeichnis befindet. Sie können allerdings mit 
Hilfe der Option -s dafür sorgen, daß andere Verzeichnisse oder 
Disketten durchsucht werden sollen (z.B. -sDiskl:;Disk2:C- 
Sources;... oder -sDiskl:!Disk2:C-Sources!...). 

-n 

Normalerweise werden alle definierten Macros abgespeichert 
(xxxx.mac). Wenn Sie vermeiden wollen, daß diese Macros gela¬ 
den werden, können Sie dies mit Hilfe dieser Option verhindern. 
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Display-Optionen 

Die nun folgenden Optionen beziehen sich auf die Farben in den 
drei Darstellungsbereichen des SDB-Fensters: 


-csT,H,hT,hH 

Mit Hilfe dieser Option bestimmen Sie die Farben für Text, 
Hintergrund, highlighted Text und highlighted Hintergrund im 
obersten Darstellungsbereich (C-Programm) des SDB-Fensters. 
Die Werte, die Sie hier angeben können, müssen zwischen 0 und 
3 liegen und geben die jeweilige Workbench-farbe an, mit der 
Text und Hintergrund dargestellt werden sollen. 


-ccU,T,H,P 

Mit Hilfe dieser Option legen Sie die Farben für die Komman¬ 
dozeile fest (Umrandungsfarbe des Kommandobereichs, Text¬ 
farbe, Hintergrund- und Promptfarbe). 


-cdT,H 

Mit Hilfe dieses Kommandos geben Sie die Farben für den Da¬ 
tenbereich des SDB-Fensters an (Text und Hintergrund). 

Beachten Sie, daß Sie alle 4 bzw. 2 Farbangaben bei der Farb¬ 
wahl festlegen müssen. 

Wenn Ihnen die Default-Farben des SDB-Fensters nicht gefallen, 
es Ihnen aber auch zu lästig ist, diese bei jedem Aufruf des SDB 
neu zu definieren, können Sie mit Hilfe der Umgebungsvariable 
SDBOPT diese Farben permanent erhalten: 

set "SDBOPT=-cs1,2,3,0 -cd,2,3,0 -cd0,1" 

(Dieser Befehl sollte in der Startup*Sequence stehen.) 

Kommen wir nun dazu, wie man beim Debuggen mit dem SDB 
vorgeht: 

Zunächst muß das zu debuggende Programm in der oben be¬ 
schriebenen Form vorliegen (Compiler-Option -n und Linker- 
Option -g). Dann wird der SDB z.B. mit 
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SDB Print Hallo 

gestartet. Der SDB wird geladen, der wiederum das Programm 
Print lädt (dem Programm Print wird der Parameter Hallo über¬ 
geben). Die ersten Zeilen des C-Programms werden im obersten 
Teil des SDB-Fensters angezeigt, wobei die Programmzeile, die 
als nächstes abgearbeitet werden soll, farbig unterlegt wird. Im 
Gegensatz zum DB brauchen Sie sich hier nicht erst mit Hilfe 
von Break-Points bis zur Routine main() vorzuarbeiten. Dies 
übernimmt der SDB für Sie (im C-Source-Modus). 

Sie können nun wie beim DB mit den Kommandos t, s und g 
durch das Programm marschieren. 

Zur Erinnerung: 

Mit s wird jeweils der nächste Befehl abgearbeitet. Wenn als 
nächstes eine Routine angesprungen werden soll, wird nach s der 
erste Befehl dieser Routine dargestellt und für den nächsten 
Einzelschritt (Single-Step) bereitgestellt. Um zu vermeiden, daß 
Sie sich erst mühsam durch alle Befehle einer funktionsfähigen 
Routine "steppen" müssen, können Sie beim Aufruf von Routi¬ 
nen das t-Kommando verwenden. Hier wird die aufgerufene 
Routine vollständig abgearbeitet und der nach dem Funktions¬ 
aufruf folgende Befehl zum Debuggen bereitgestellt. Mit g wird 
das Programm gestartet (ähnlich dem RUN-Befehl des Amiga- 
BASIC) und erst gestoppt, wenn ein Break-Point erkannt wird 
oder das Programm vollständig abgearbeitet wurde. (Es gibt hier 
im Gegensatz zum DB keine Möglichkeit, die Abarbeitung des 
Programms durch einen beliebigen Tastendruck zu unterbre¬ 
chen.) 

Auch das Setzen von Break-Points geschieht beim SDB genauso 
wie beim DB. Mit Hilfe des Kommandos bs werden Break- 
Points gesetzt (z.B. bs Write). Wenn bei der Abarbeitung eines 
Programms auf solch einen Break-Point gestoßen wird, wird das 
Programm unterbrochen, und Sie können ab dieser Stelle das 
Programm debuggen. 
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Mit Hilfe dieser 4 Befehle kann man ein Programm schon sehr 
effektiv debuggen. Jedoch wollen wir Ihnen die restlichen (und 
sehr kraftvollen Befehle) des SDB nicht vorenthalten. Dazu muß 
jedoch bekannt sein, welches Format z.B. ein AUSDRUCK, 
BEREICH usw. hat: 


AUSDR: (EXPR) 

Ein Ausdruck ist jeder gültige Ausdruck der Sprache C. Z.B: 
c++, i = i*2, (i==2) ? k:l, printf("Hallo") usw. 


ADDR: 

Eine Adresse ist entweder der Name einer C-Variable (oder ei¬ 
ner Routine), eine absolute Adresse (z.B. 0x123456) oder ein C- 
Ausdruck, von dem eine Adresse ermittelt werden kann. Bei¬ 
spiele: 


.23:23ste Zeile des aktuellen Programms 

Modul.c.23: 23ste Zeile des Programms Modul.c. Mit Hilfe dieser 
Adressen ist es möglich, Programme zu debuggen, die aus meh¬ 
reren Modulen bestehen. 

main 

Adresse der Routine main(). 

Arraylk] 

Adresse des k-ten Elements des Arrays. 
i 

Adresse der Variable i. 
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BEREICH: (RANGE) 

Ein Bereich wird benötigt, um z.B. festzulegen, welchen Umfang 
eine Ausgabe annehmen soll. Der Bereich bestimmt z.B., welcher 
Teil eines C-Programms aufgelistet werden soll. 

Definiert ist ein Bereich wie folgt: 

a. ADDR, ZÄHLER 

b. ADDR to ADDR (Schlüsselwort to muß angegeben werden) 

c. ADDR 

d. ZÄHLER 

Mit a wird z.B. die erste Zeile festgelegt und mit ZÄHLER 
(ganze Zahl (Basis: dezimal)) die Anzahl der Zeilen, die ab der 
angegebenen Adresse ausgegeben werden sollen. 

Mit b wird der Bereich durch zwei Adressen festgelegt. 

Bei c wird der vorher verwendete ZÄHLER-Wert verwendet, 
während bei d ein neuer ZÄHLER definiert und die zuletzt er¬ 
reichte Adresse (z.B. ADDR+ZÄHLER) verwendet wird. 


CMDUST: 

Eine Kommandoliste ist eine Aneinanderreihung von Komman¬ 
dos, die jeweils durch ein Semikolon getrennt sind. Solche 
Kommandolisten werden häufig zur Definition von Macros ver¬ 
wendet. Hieraus resultiert, daß in dem Fall, daß ein Macro (auch 
eine Ansammlung von Kommandos) Teil einer CMDLIST sein 
soll, dieses am Ende dieser steht. Mögliche Formate sind: 

Kommandol [;Kommando2 ...] 

Nachdem diese Definitionen geklärt sind, wollen wir Ihnen nun 
die einzelnen Kommandos des SDB vorstellen. Dabei werden Sie 
feststellen, daß die Syntax vieler Befehle auf diese Definitionen 
(BEREICH, ADDR, AUSDR, CMDLIST) zurückgreift. Machen 
Sie sich diese deshalb zu eigen. Meistens kommt die Kenntnis 
dieser Definitionen aber durch das häufige Arbeiten mit dem 
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Debugger. Da man sehr schnell Vorlieben für bestimmte Er¬ 
scheinungsformen dieser Definitionen entwickelt, fällt es nicht 
schwer, sich diese zu merken.) 

Ein kleiner Hinweis noch: 

Das Debugging-Fenster setzt sich ja aus drei Teilen zusammen. 
Mit Hilfe der Tastenkombinationen <Shift>+<Alt>+<Crsr Up> 
und <Shift>+<Alt>+<Crsr Down> können Sie die Position der 
Kommandozeile verändern. Dabei wird Platz für den oberen 
oder unteren Darstellungsbereich frei. Mit Hilfe der Tasten 
<Shift>+<Crsr Up> und <Shift>+<Crsr Down> wird im C-Source 
"geblättert", während mit <Alt>+<Crsr Up> und <Alt>+<Crsr 
Down> im unteren Darstellungsbereich geblättert werden kann. 
(Diese Funktionen können auch mit Hilfe der Maus und der Sli- 
der am rechten Fensterrand aufgerufen werden.) Wenn Sie nur 
die Cursor-Tasten verwenden, werden im Kommandobereich die 
vorigen Befehle angezeigt, bzw. der Cursor innerhalb der Kom¬ 
mandozeile bewegt (die Kommandozeile erlaubt volle Editierung 
der Befehle). 

acc [U, T, H, P] 

Mit Hilfe dieses Befehls setzen Sie entweder die Farben für die 
Kommandozeile (Umrandungs-, Text-, Hintergrund- und 
Promptfarbe) oder lassen sich die aktuelle Farbdefinition anzei- 
gen. Die Defaultwerte sind 1,1,0,1. Beachten Sie, daß bei einer 
Änderung alle 4 Farbdefinitionen angegeben werden müssen. 

acd [T, H] 

Mit Hilfe dieses Befehls werden die Farben für den Datenbe¬ 
reich des SDB-Fensters festgelegt bzw. angezeigt (Text- und 
Hintergrundfarbe). Die Defaultwerte sind: 1, 2. 

acs [T, H. hT hHJ 

Mit Hilfe dieses Kommandos werden die Farben für den oberen 
Bereich (C-Source-Darstellung) des SDB-Fensters festgelegt bzw. 
angezeigl (Text, Hintergrund, highlighted Text, highlighted 
Hintergrund). Die Defaultwerte sind: 1,0,1,3. 
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add 

Alle im System momentan vorhandenen Devices anzeigen. 
adi 

Alle im System momentan vorhandenen Interrupts anzeigen. 
adl 

Alle im System momentan vorhandenen Librarys anzeigen. 
adp 

Mit Hilfe dieses Befehls werden alle im System momentan vor¬ 
handenen und mit Namen versehenen Message-Ports angezeigt. 

adr 

Alle im System momentan vorhandenen Resources anzeigen. 
ae 

Mit Hilfe dieses Befehls, der wie ein Schalter wirkt, können Sie 
dafür sorgen, daß alle eingegebenen Kommandos auch im Da¬ 
tenbereich (unterster Teil) des SDB-Fensters angezeigt werden 
(siehe Option -e beim Aufruf des SDB). 

am 

Dieser Befehl gibt Ihnen Auskunft über den momentan freien 
Speicher. 

ax 

Da man mit dem SDB auch eigene Librarys und Devices debug- 
gen kann (siehe 11 und Id), ist es zeitweise so, daß der SDB zwei 
Symbol-Tabellen verwalten muß. Zum einen wird die Tabelle 
der Library oder des Devices benötigt, und zum anderen die Ta¬ 
belle des Test-Programms (ohne Programm kann man Librarys 
oder Devices nämlich nicht debuggen). Mit Hilfe dieses Kom¬ 
mandos kann man nun zwischen beiden Symbol-Tabellen hin- 
und herspringen. 
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bc ADDR 
bC 

Mit Hilfe dieses Befehls werden ein einzelner (bc) oder alle (bC) 
Break-Points gelöscht. 

bd 

Dieses Kommando listet alle Break-Points auf. Ebenso wie beim 
DB haben Sie auch beim SDB die Möglichkeit einen Skip-Count 
und ein auszuführendes Kommando anzugeben. Diese beiden 
Informationen werden auch hier bei der Ausgabe berücksichtigt. 
Jedoch weicht die Ausgabe der Break-Point-Adresse ein wenig 
von der des DB ab: 

# address hits skip conmand 

1 413f6 alt.c.504 0 0 

Zunächst wird die laufende Nummer des Break-Points angege¬ 
ben. Dann wird die Adresse des Break-Points ausgegeben. Wie 
Sie sehen, wird die Zeile innerhalb des Programms angegeben. 
Auch wenn ein Break-Point z.B. wie folgt gesetzt wurde: "bs 
main", so wird dennoch nur die Adresse (Zeile) innerhalb des C- 
Programms ausgegeben. Nach der Adresse wird die Anzahl der 
"Treffer" ausgegegen - also die Anzahl der bisherigen "Berüh¬ 
rungen" dieses Break-Points, skip gibt an, nach wie vielen 
Treffern tatsächlich das Programm an dieser Stelle unterbrochen 
werden soll, command schließlich enthält das Kommando, das 
beim Auftreten dieses Break-Points ausgeführt werden soll. 

be AU SDR 

Mit Hilfe dieses Kommandos wird ein Expression-Change- 
Break-Point gesetzt. Wenn also eine Veränderung bei dem ange¬ 
gebenen Ausdruck auftritt (z.B. Veränderung einer Variablen), 
wird das Programm unterbrochen. Wird das g-Kommando für 
den Ablauf des Programms verwendet, wird der Ausdruck nur 
bei jedem Eintritt in bzw. Austritt aus einer Funktion überprüft 
(Zeitersparnis). Bei der Verwendung von s und t wird der Aus¬ 
druck nach jedem einzelnen dieser Kommandos überprüft. 
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br [ADDR ] 

Dieses Kommando löscht die hit- und skip-Zähler des angege¬ 
benen, bzw. aller Break-Points. 

[#] bs ADDR f.CMDLISTJ 

Mit Hilfe dieser Routine wird ein Break-Point gesetzt. Wenn 
während des Programmablaufs der Programmcounter die angege¬ 
bene Adresse erreicht, wird eine Unterbrechung ausgelöst. Wenn 
Sie beim Setzen eines Break-Points ein Kommando angegeben 
haben, wird dieses nach der Unterbrechung ausgeführt (z.B. 
Darstellung eines Speicherbereichs und anschließende Weiterbe¬ 
arbeitung des Programms). Wenn Sie vor dem Schlüsselwort bs 
noch eine Zahl angeben, so gibt diese Zahl Aufschluß darüber, 
nach dem wievielten Mal des Erreichens dieser Adresse durch 
den Programmcounter (Treffer) tatsächlich eine Unterbrechung 
ausgelöst werden soll. 

bt, bT 

Diese Kommandos erlauben Ihnen das Setzen des sogenannten 
Trace- bzw. Source-Line-Trace-Modus. Beim Trace-Modus wird 
bei der Abarbeitung des Programms (mit g) jede Funktion in¬ 
klusive Parameter angezeigt, in die verzeigt wurde. Wird diese 
Routine verlassen und hat diese einen Rückgabewert, so wird 
auch dieser angezeigt. Normalerseis ist dieser Modus ausgeschal¬ 
tet. Jedoch wirkt das bt-Kommando auf diesen Modus wie ein 
Schalter. 

Der Source-Line-Trace-Modus äußert sich darin, daß jede Zeile 
des C-Programms, die gerade abgearbeitet wird, farbig hinter¬ 
legt (highlighted) wird. Auch hier wirkt das bS-Kommando wie 
ein Schalter, der diesen Modus an- bzw. ausschaltet. 

c 

Dieses Kommando sorgt dafür, daß die aktuelle C-Zeile im 
Ausgabefenster zentriert wird (Center-Funktion). 

da, dA 

Diese beiden Befehle sorgen dafür, daß die "automatischen" Va¬ 
riablen der aktuellen Routine angezeigt werden. Automatische 
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Variablen sind sowohl diese mit der Speicherklasse auto, als auch 
die, die innerhalb von Routinen definiert werden, und demge¬ 
mäß ihren Speicher vom Stack beziehen. Nach da werden alle 
Auto-Variablen der aktuellen Routine, sowie deren augenblick¬ 
lichen Werte ausgegeben. Nach dA werden nur die Adressen 
dieser Variablen preisgegeben. 

db [BEREICH] 
dw [BEREICH] 
dl [BEREICH] 
d 

Mit Hilfe dieser Befehle ist es möglich, einen bestimmten 
Speicherbereich in Bytes (db), Words (dw) oder Longwords (dl) 
ausgeben zu lassen. Bei erneutem Aufruf eines dieser Befehle 
ohne Bereichsangabe wird mit der Darstellung ab der vorher zu¬ 
letzt dargestellten Adresse begonnen, wobei die Anzahl anzuzei¬ 
gender Bytes, Words oder Logwords vom vorigen Aufruf be¬ 
stimmt wird, d verwendet das vorige Ausgabeformat, die zuletzt 
dargestellte Adresse, sowie die vorige Anzahl dargestellter Werte. 

de 

Alle globalen Code-Symbole anzeigen (Routinen). 
dd 

Mit Hilfe dieses Kommandos werden alle globalen Daten-Sym- 
bole (Variablen) aufgezeigt. 

df [FILENAME] BEREICH 

Mit Hilfe dieses Befehls werden die durch BEREICH festgeleg¬ 
ten C-Zeilen des aktuellen bzw. angegebenen Programms ange¬ 
zeigt. 

dg 

Alle globalen Variablen sowie deren Werte anzeigen. 
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[#] ds 
[#] dS 

Mit Hilfe dieser beiden Kommandos können Sie ermitteln, von 
welcher Routine die aktuelle Routine aufgerufen wurde, und 
von welcher dieser auf gerufen wurde, und von welcher diese 
auf gerufen wurde, ... Neben den Namen der Routinen werden 
auch ihre Parameter und Rückgabewerttypen angezeigt. Bei dS 
werden außerdem die Werte aller Auto-Variablen angezeigt. 

fu, fd 

Da es eigentlich nicht möglich ist, lokale Variablen anderer 
Routinen zu betrachten, wurden diese beiden Kommandos ein¬ 
geführt. Mit fu (Frame Up) können Sie in die jeweils aufru¬ 
fende Routine aufsteigen, um dort die lokalen Variablen zu be¬ 
trachten. Mit fd steigen Sie dann wieder in die jeweils aufge¬ 
rufene Routinen hinab. 

f*J 8 f@ [Fmktionsname]] [ADDR] [ iCMDLIST] 

[*] G [@ [Funktionsname]] [ADDR] [:CMDLIST] 

Mit Hilfe dieser beiden Kommandos kann ein Programm ausge¬ 
führt werden. Dabei wird nach g beim Auf tauchen eines Break- 
Points evt. (je nach skip# und hit) eine Unterbrechung hervor¬ 
gerufen, während G alle vorher gesetzten Break-Points ignoriert. 
Sie haben beim Aufruf des g- bzw. G-Kommandos die Mög¬ 
lichkeit genauso wie bei bs einen Break-Point festzulegen (In¬ 
klusive Skip und Kommando). Beim G-Kommando wird al¬ 
lerdings nur dieser Break-Point akzeptiert. Eine besondere Art 
Break-Point wird mit g @ [Funktion] bzw. G @ [Funktion] ge¬ 
setzt: Hier wird dafür gesorgt, daß der Programmablauf unter¬ 
brochen wird, wenn aus der angegeben bzw. aktuellen Funktion 
zurückgekehrt wird. 

Id DeviceName 
ll LibraryName 

Ip [[progfile] [argl arg2 ...]] 

Mit Hilfe dieser Befehle wird ein Programm zum Debuggen in 
den Speicher des SDB geladen. Sie können das Programm ge¬ 
nauso aufrufen wie im CLI - also inklusive aller Kommando- 
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Parameter. Wird der Ip-Befehl ohne Parameter ausgeführt, wer¬ 
den die Parameter des letzten Ip-Befehls verwendet. Dies ist z.B. 
dann recht nützlich, wenn ein vollständig abgearbeitetes Pro¬ 
gramm erneut debugged werden soll. 

Sie haben allerdings auch die Möglichkeit, eigene Librarys oder 
Devices zu debuggen. Dazu braucht nur das Device oder die Li¬ 
brary mit dem Id- bzw. Il-Kommando in den Speicher geladen 
zu werden (z.B. 11 eigenelibrary ohne ".library"-Tag). Allerdings 
muß vorher ein Testprogramm, daß die Libary bzw. das Device 
testet, mit Ip geladen worden sein. Mit 11 bzw. Id werden dann 
die Symbole der Library bzw. des Device geladen. 

mb ADDR WERTl [WERT2 ..] 
mw ADDR WERT! [WERT2 ..] 
ml ADDR WERTl [WERT2 ..] 

Mit Hilfe dieser Kommandos können Sie Werte in den Arbeits¬ 
speicher übertragen. Dazu wird die Anfangsadresse des ersten zu 
ändernden Wertes übergeben (auf gerade Adressen bei mw und 
ml achten!). Die angegebenen Werte werden ab der angegebenen 
Adresse in den Speicher übertragen. 

mc BEREICH = ADDR 

Dieser Befehl erlaubt Ihnen zwei Speicherbereiche zu verglei¬ 
chen. Die Adresse des ersten Speicherbereichs sowie die Anzahl 
zu vergleichender Bytes wird im BEREICH festgelegt. Der 
zweite Speicherbereich wird durch ADDR bestimmt. 

mf BEREICH = WERT 

Mit Hilfe dieses Kommandos ist es möglich, einen Speicherbe¬ 
reich mit einem bestimmten Wert zu füllen. Beachten Sie, daß 
der BEREICH korrekt ist, da sonst der Rechner abstürzen 
könnte. 

mm BEREICH = ADDR 

Mit Hilfe dieses Kommandos wird der angegebene Bereich an 
die angegebene Adresse kopiert. 
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ms BEREICH = WERTl [WERT2 ..] 

Mit Hilfe dieses Kommandos wird der angegebene Bereich byte¬ 
weise nach der angegebenen Byte-Folge durchsucht. Es werden 
die Adressen aller entdeckten Byte-Folgen angezeigt. 

Q 

Mit diesem Befehl wird der SDB verlassen (Quit). 
r [REGISTER=Wert] 

Mit Hilfe dieses Kommandos können Sie entweder die Inhalte 
aller Register auflisten lassen oder ein bestimmtes Register (AO- 
A7, D0-D7, SP, SR und PC) verändern. 

[*1 s 

[*J s 

[*]t 
[#] T 

Mit Hilfe dieser Kommandos können Sie durch ein Programm 
befehlsweise fortschreiten. Bei s wird ein einziger Befehl ab¬ 
gearbeitet. Nach s werden die Registerinhalte angezeigt. S funk¬ 
tioniert genauso wie s - bis auf die Tatsache, daß auf die Aus¬ 
gabe der Registerinhalte verzichtet wird. 

Mit Hilfe der Kommandos t und T (keine Registerausgabe) kön¬ 
nen ganze Unterroutinen wie ein Befehl behandelt werden. Wenn 
Sie also wissen, daß eine bestimmte Funktion fehlerfrei ist, 
müssen Sie sich nicht durch jeden einzelnen Befehl dieser Rou¬ 
tine mit den s-Kommandos quälen, sondern können den ge¬ 
samten Funktionsaufruf mit t bearbeiten. 

Mit # bestimmen Sie die Anzahl aufeinanderfolgender s- bzw. 
t-Aufrufe. 

u [BEREICH] 

U [BEREICH] 

Mit Hilfe dieser beiden Befehle können Sie den angegebenen 
BEREICH disassemblieren lassen. Bei u wird auf die Symbolta- 
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belle zurückgegriffen, während U nur mit absoluten Adressen 
arbeitet. 

Wenn Sie den BEREICH weglassen, wird mit der Darstellung des 
disassemblierten Codes ab der letzten disassemblierten Zeile be¬ 
gonnen. Die Anzahl der dargestellten Zahlen richtet sich nach 
der letzten Anzahl dargestellter Zeilen. 

X MacroName [ CM DL IST ] 

X 

Mit Hilfe dieser beiden Befehle können Macros definiert, ange¬ 
zeigt oder ausgeführt werden. Die Definition eines Macros er¬ 
folgt z.B. so: 

X Macro lp;db main,23 

Ausgeführt wird dieses Macro mit "x Macro". Beachten Sie, daß 
die Schreibweise (Groß-, Kleinschreibung) des Macro-Namens 
(maximal 40 Zeichen) keinen Einfluß hat. 

Mit X werden alle definierten Macros aufgelistet. 

= AUSDR 
eAUSDR 

Mit Hilfe dieses Kommandos werden C-Ausdrücke ausgewertet. 
Erlaubt sind solch einfache Ausdrücke wie 1+2. Aber auch ganze 
Funktionsaufrufe sind erlaubt, wobei hier der Rückgabewert an¬ 
gezeigt wird (z.B. = Write (OutputFile, "Hallo", 5L). Beachten 
Sie, daß die benötigten Librarys und Variablen ordnungsgemäß 
initialisiert sind. 

z 

Mit Hilfe dieses Kommandos wechseln Sie zwischen dem 
Source-Modus und dem Assembler-Modus des SDB. Der SDB 
verhält sich nach diesem Kommando nämlich wie der "einfache" 
DB. Nach erneutem Aufruf dieses Kommandos ist der SDB wie¬ 
der ein Source-Level-Debugger. 
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/"STRING" 

Mit Hilfe dieses Kommandos kann nach dem angegebenen String 
im C-Source gesucht werden. Mit der Suche wird dabei ab der 
augenblicklichen Zeile im C-Source-Code begonnen. 

> File 

< File 
>> Fiie 

Mit Hilfe dieser Kommandos können Sie die Ein- und Ausgaben 
umlenken: 

< File sorgt dafür, daß die Eingaben nicht mehr von der Ta¬ 
statur, sondern aus dem angegebenen File erfolgen. Dies ge¬ 
schieht solange, bis das File vollständig gelesen wurde. 

> File sorgt dafür, daß alle Ausgaben (Registerinhalte, etc.) in 
das angegebene File geschrieben werden. Dies geschieht solange, 
bis entweder ein neues Ausgabe-File festgelegt oder nur > auf¬ 
gerufen wird. Während der Ausgabe auf ein File wird auch das 
Window wie gewohnt verwendet. 

» File sorgt dafür, daß nur Kommandos in das angegebene File 
geschrieben werden. Dies ist z.B. dann recht nützlich, wenn der 
Debugging-Vorgang sehr kompliziert ist und häufig wiederholt 
werden muß (siehe: < File). Diese Option ist zu vergleichen mit 
dem Spielstand-Speichern bei einem Adventure - nicht allein 
deshalb, weil das Debuggen zu einem aufregenden und ner¬ 
venaufreibenden Abentuer werden kann. 

Mit Hilfe dieses Kommandos können Sie sich eine Übersicht der 
SDB-Kommandos holen. 


2.5 Programmiertechniken 

Zu einem großen C-Buch gehört auch die Beschreibung der 
gängigsten Programmiertechniken. In diesem Kapitel wollen wir 
Ihnen zeigen, wie Sie auf absolute Speicherstellen zugreifen. 



146 


Das große C-Buch zum Amiga 


Funktionsarrays anlegen, Files öffnen und benutzen und Direc- 
torys anzeigen können. 


2.5.1 Der Zugriff auf absolute Speicherstellen 

Sicher haben auch Sie sich schon einmal gefragt, wie man in ei¬ 
nem C-Programm absolute Speicherstellen abfragen kann, ohne 
erst Librarys, Devices oder Resources öffnen zu müssen. 

Am einfachsten geschieht dieser Zugriff mit Hilfe von Zeigern. 
Wie Sie wissen, enthalten Zeigervariablen Adressen auf Spei¬ 
cherstellen, die wiederum Werte enthalten. Unsere Aufgabe be¬ 
steht also nur darin, der Zeigervariable mitzuteilen, auf welche 
Speicherstelle diese zeigen soll. 

Normalerweise wird dies ja symbolisch durch Ausdrücke wie 
Zeiger = ÄVariable erledigt. Aber man kann Zeiger ja auch lö¬ 
schen (Zeiger = OL;). Was ist dies aber anderes als die Zuwei¬ 
sung der Adresse 0 an den Zeiger? 

Wenn also dies funktioniert, dann auch Zeiger = Oxabcdef. Be¬ 
achten muß man hierbei nur noch, daß die Zuweisung korrekt 
ist, daß also eine Typumwandlung (CAST) durchgeführt wird. So 
akzeptiert der Compiler solch eine Zuweisung ohne jegliche 
Meldung. 

Folgendes Programm erzeugt einen Zeiger auf die Speicherstelle 
OxbfeOOl. Dieses Hardwareregister des CIA-A gibt Ihnen neben 
dem Status der Power-LED auch Auskunft über den Status der 
Feuerknöpfe angeschlossener Joysticks oder Mäuse. Das Pro¬ 
gramm sorgt nun solange dafür, daß die LED dunkel bleibt, bis 
die linke Maustaste gedrückt wurde: 

#define Absolute_Adresse OxbfeOOl 

char *CIAA_Reg1; /* Zeigerdefinition V 

#define MausKnopfB 6 /* Mausknopf Bit */ 

#define LEDB 1 /* LED Bit V 


#define MausKnopfF (1«MausKnopfB) /* Flags (Masken) */ 

#define LEDF (1«LEDB) 
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mainO 

int i; /* Zählvariable V 

CIAA_Reg1 = (char *)Absolute_Adresse; /* Adressenzuweisung */ 

printfC'BLINK läuft. Warte auf MausklickVn"); 

i=0; 

*CIAA_Reg1 |= LEDF; /* Bit setzen V 

while ((*CIAA_Reg1 & MausKnopfF) == MausKnopfF); 

/* Mausknopf gedrückt? 

*CIAA_Reg1 &= (Oxff-LEDF); /* Bit löschen V 

> 


Programm Blink.c 


Beachten Sie, daß die hier verwendeten Bits Low-Activ sind. 
Das heißt, daß bei gesetztem Bit (Bit 6 dieses Registers) die 
Maustaste nicht gedrückt ist, während bei gelöschtem Bit die 
linke Maustaste niedergedrückt wurde. 

Ähnlich ist es mit dem Bit für die Power-LED (Bit 1). Ist dieses 
Bit gesetzt, leuchtet die LED dunkel. Bei gelöschtem Bit leuchtet 
die LED hell. 

Bei der Verwendung von Zeigern auf absolute Speicheradressen 
gilt es zu beachten, daß die Adresse in Einklang mit dem Zei¬ 
gertyp steht. Wenn Sie z.B. einem Zeiger auf ein Wort oder 
Langwort eine ungerade Adresse zuweisen und dann mit Hilfe 
dieses Zeigers versuchen, die Speicheradresse anzusprechen, 
führt dies zu einem Systemabsturz, da Wörter und Langwörter 
nur an geraden Adressen liegen dürfen. 


2.5.2 Schalter In der Kommandozelle 

"Was hat man sich unter dieser Überschrift vorzustellen?" wer¬ 
den Sie sich sicher fragen. Sie alle kennen doch Programme, 
denen man beim Aufruf mitteilen kann, was wie zu passieren 
hat. Der Compiler ist hierfür ein gutes Beispiel. 
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Wie Sie wissen, können Sie mit Hilfe der Option -o festlegen, 
wohin das Output-File (daher der Name dieser Option) geschrie¬ 
ben werden und welchen Namen es erhalten soll. Neben der Op¬ 
tion -0 existieren allerdings weitere Optionen. So z.B. die Option 
-s, die dafür sorgt, daß alle Warnings unterdrückt werden. 


Wie programmiert man soiche SchaKer bzw. Optionen? 

Betrachten wir dazu einmal folgendes Programmsegment: 

BOOL NewOutputFlag = FALSE; 

BOOL NoWarnings - FALSE; 

char *NewOutputFileName = OL; 

main(argc, argv) 
int arge; 
char *argv[]; 
i 

1 nt i ; 

for (i=1;i<argc;i++) /* Programmnamen übergehen */ 

C 

if (argvCi][0] == *-*) /* Optionspräfix V 
i 

switch(argv[i][1]) /* Option V 

case ' 0 ': /* anderes als Default-Output-File V 
NewOutputFi lename = &argv[i][2]; 

NewOutputFlag = TRUE; 
break; 

case 's': /* Silent-Option (keine Warnings) */ 
NoWarnings = TRUE; 
break; 


default: 

/* Option ignorieren */ 

/* oder Benutzerhinweis auf unbekannte Option */ 

> 

> 

> 


/* Output-File öffnen */ 
if (NewOutputFile) 

L 

/* Öffne neues File mit Namen *0utputFilename V 

> 

eise /* Öffne neues File mit Default-Namen V 
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/* (z.B. mit Extension . 0 ) */ 


/* Compilieren •/ 
if (Warning_aufgetreten) 
if(!NoUarnings) 

/* Warnung ausgeben */ 

> 


> 

Man untersucht zunächst jeden Kommandozeilen-Parameter 
darauf, ob der erste Buchstabe eines Parameters (argv[i][0]) ein 
Optionspräfix ist (-). Ist dies der Fall, wird der zweite Buchstabe 
(argv[i][l]) daraufhin untersucht, ob er der Einleitung einer gül¬ 
tigen Option dient. Ist dies nicht der Fall, so kann man je nach 
Bedarf den Benutzer darauf hinweisen, daß er eine unbekannte 
Option angegeben hat und dann evt. das Programm abbrechen. 

Im Verlauf des Programms kann dann anhand der booleschen 
Variablen, die bei Erkennen einer Option gesetzt werden, der 
Ablauf beeinflußt werden. Allerdings gilt es zu beachten, be¬ 
stimmte Optionskonstellationen auszuschließen. Stellen Sie sich 
vor, daß Sie eine Option zum Erzeugen eines neues Files und 
eine zum Erweitern eines bestehenden Files zur Verfügung stel¬ 
len. Wählt der Benutzer nun beide Optionen aus, so muß hier 
doch wohl ein Irrtumm vorgefallen sein. Schließlich kann man 
ein File nicht neu anlegen und gleichzeitig erweitern. Der Pro¬ 
grammierer muß also dafür sorgen, daß sich ausschließende Op¬ 
tionen nicht ins Gehege kommen und so evt. Daten verloren ge¬ 
hen. 


2.5.3 Funktionstabellen 

Nun wollen wir Ihnen einen kleinen Vorgeschmack auf das 
Thema Intuition geben. Wie Sie vielleicht wissen, haben Sie mit 
Hilfe von Intuition die Möglichkeit, Menüs zu programmieren. 

Wenn Sie einen Menüpunkt ausgewählt haben, so erhalten Sie 
von Intuition die Nummer des Menüs sowie die Nummer des 
Menüpunktes. 
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Sie haben nun die Möglichkeit, die einzelnen auszuführenden 
Funktionen durch Switch-Anweisungen auszuwählen: 

switch(Menu) 

C 

case 0: /♦ Projekt Menü V 
switch(Menüpunkt) 
i 

case 0: /* Info */ 

• ■ •» 

break; 

case 1: /* Speichern V 
•..; 
break; 

case 2: /* Laden */ 

... ; 

break; 

> 

break; 

case 1: /* Bearbeiten */ 

switch(Menüpunkt) 

C 

case 0: /* Neue Schriftart */ 

... ; 

break; 

case 1: /* Funktionstasten*Belegung */ 

■ ■ ■; 
break; 

• ■ • # 

> 

break; 


> 

Wie Sie sehen, ist die Selektion der Routinen, die nach dem 
Anwählen eines bestimmten Menüpunktes angesprungen werden 
sollen, recht aufwendig. 

Viel einfacher ist es doch, eine Funktionstabelle anzulegen, die 
die Funktionen enthält, die je nach ausgewähltem Menü aufge¬ 
rufen werden sollen: 

VOID (*Funktionen[MaxMenues][MaxMenuePunkte])(); 
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Jetzt brauchen wir nur die aufzurufenden Funktionen an das 
Array zu übergeben, 

#clefine PROJEKT 0 
#define INFO 0 
#define SPEICHERN 1 
#define LADEN 2 

#define BEARBEITEN 1 
«define NEUESCHRIFT 0 
«define FTASTEN 1 

FunktIonen[PROJEKT] [INFO] = Info; 

Funktionen[PROJEKT][SPEICHERN] = Speichern; 

Funktionen[PROJEKT][LADEN] = Laden; 

Funktionen[BEARBEITEN][NEUESCHRIFT] = NeueSchrift; 

Funktionen[BEARBEITEN][FTASTEN] = FTasten; 


und dann die jeweilige Funktion je nach Menüpunkt aufrufen: 
Funkt 1 onen[Menü][MenüPunkt] (); 

Hier wird allerdings davon ausgegangen, daß alle Funktionen 
keinen Rückgabewert besitzen, also vom Typ VOID sind. 
Außerdem müssen alle Funktionen (Info(), Speicher(), Laden(), 
usw.) vor der Zuweisung an das Array, also vor main() oder der 
Routine, innerhalb der diese Zuweisung stattfindet, definiert 
worden sein. 

Ein Nachteil den Funktionstabellen haben ist die Tatsache, daß 
alle enthaltenen Funktionen den gleichen Rückgabewert haben. 
Allerdings ist dies auch wieder nicht so tragisch. Wenn man alle 
Funktionen des Funktionsarrays als Funktionen mit Rückgabe¬ 
wert des Typs ULONG deklariert, kann man dann, wenn man 
einen diese Routinen einen Rückgabewert liefert, diesen in den 
jeweiligen Typ wandeln. 

Hier wäre es allerdings angebrachter, gobale Variablen zu be¬ 
nutzen, was allerdings mehr Übersicht bei der Programmierung 
verlangt. 
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2.5.4 File-Handling 

Ein Problem, das sich dem Programmierer recht häufig stellt, ist 
die Datenein- und -ausgabe. Ausgaben auf den Bildschirm kön¬ 
nen noch recht einfach mit Hilfe des printf()-Befehls getätigt 
werden. Auch Eingaben lassen sich leicht mit scannf() realisie¬ 
ren. Um aber Daten abzuspeichern, sind einige Schritte nötig. 

Leider hat sich gezeigt, daß viele Programmierer die Vorsichts¬ 
maßnahmen, die hier geboten sind, vernachlässigen. Dies ist eine 
häufige Ursache für Systemabstürze. Um Ihnen hier zu helfen, 
wollen wir uns im nun folgenden Kapitel mit der Erzeugung von 
Dateien befassen. Darüber hinaus werden wir Ihnen auch ein 
paar Tips und Kniffe für das Umfeld der Dateiprogrammierung 
geben. Sie werden z.B. erfahren, wie man feststellt, ob ein zu 
öffnendes File schon existiert, welche Files auf der Diskette 
oder in einem Unterverzeichnis der Diskette enthalten sind, 
welche Informartionen über eine Datei (bzw. über ein File) vom 
System zur Verfügung gestellt werden und wie man an diese 
herankommt. 


2.5.4.1 Das öffnen und Schließen von Dateien 

Wie nicht anders zu erwarten, müssen auch Dateien geöffnet 
werden. Es gibt nahezu nichts auf dem Amiga, was nicht vor 
Benutzung geöffnet werden muß. Man denke nur an Librarys 
und Devices. 

Um eine Datei zu öffnen bzw. neu anzulegen, wird das Open()- 
Kommando der DOS-Library verwendet. Keine Angst! Die 
DOS-Library gehört zu den beiden Librarys, die dem Benutzer 
innerhalb eines C-Programms sofort zur Verfügung stehen. 
EXEC- und DOS-Library sind diejenigen Librarys, die inner¬ 
halb des Startup-Codes eines jeden C-Programms geöffnet wer¬ 
den. Dies entbindet Sie als C-Programmierer von der lästigen 
Library-Eröffnung. 

Betrachten wir einmal einen typischen Open()-Aufruf: 
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#include "libraries/dos.h" 
#include "libraries/dosextens.h" 


struct FileHandle *DateiSch luessei = OL; 

Siehe "libraries/dos.h” V 


Datei Sch luessei = (struct FileHandle*) 

Open(FileName, (ULONG) MOOE^NEWFILE); 
if (DateiSch luessei == OL) 

C 

printfC'Die Datei <%s> konnte nicht erzeugt werden M!", 
FileName); 

/* exit((ULONG) RETURN_ERROR); */ 

/* oder Aufruf einer Fehlerbehandlungsroutine */ 


Close(DateiSch luessei); 


Wie Sie sehen, wird dem Open()-Befehl der Name der zu öff¬ 
nenden Datei übergeben. Dies ist ein normaler - also mit \000 
abgeschlossener - String. Das zweite Argument, das dem Open()- 
Befehl übergeben wird, ist eine Modus-Variable. Diese gibt an, 
ob ein bestehendes File geöffnet (MODE_OLDFILE) oder ein 
neues File erzeugt werden soll. 

Betrachten wir diese beiden Modi einmal genauer: 

#define MOOE_OLDFILE 1005 (s. "libraries/dos.h") 

Dieser Modus veranlaßt den Open()-Befehl, den Dateischlüssel 
auf ein schon bestehendes File zu erzeugen. Existiert allerdings 
das File, das man öffnen möchte, gar nicht, so erzeugt Open() 
hier ein neues, leeres File. 

#define HODE_NEWFILE 1006 

Dieser Modus veranlaßt den Open()-Befehl, in jedem Fall ein 
neues File zu erzeugen. Wenn noch kein File mit dem angegebe¬ 
nen Namen existierte, erzeugt Open() hier ein neues, leeres File. 
Was passiert aber, wenn Open() festgestellt hat, daß schon ein 
File mit dem angegebenen Namen existiert? Nun ganz einfach: 
Open() sorgt dafür, daß das existierende File gelöscht wird (!) 
und erzeugt im Anschluß daran ein neues File. Beachten Sie, 
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daß der Open()-Befehl davon ausgeht, daß Sie tatsächlich ein 
neues File anlegen wollen. Sie werden von Open() nicht befragt, 
ob das schon existierende File wirklich gelöscht werden soll oder 
nicht. (Sie können jedoch feststellen, ob das zu öffnende File 
schon existiert. Dazu später mehr.) 

Was passiert jedoch, wenn die Diskette, auf der Sie das File un¬ 
terbringen wollen, einen Schreib-/Lesefehler hat oder ganz ein¬ 
fach schon vollkommen gefüllt ist? Nun, Sie werden sich sicher 
sagen; Es erscheint einfach ein Systemrequester, der mich auf 
diesen Fehler hinweist und das war’s. 

Leider war es das nicht. Schließlich muß Ihr Programm darauf 
reagieren, daß solch ein Fehler aufgetreten ist. Erkannt wird ein 
Fehler beim Öffnen eines Files daran, daß der von Open() zu¬ 
rückgegebene Dateischlüssel den Wert 0 hat. 

Ist dies der Fall, können Sie entweder das Programm mit exit() 
verlassen oder in eine eigene Fehlerbehandlungsroutine springen, 
die den Benutzer auf den Fehler hinweist und ihn z.B. auffor¬ 
dert, eine neue Diskette einzulegen. (Beachten Sie bitte, daß Sie 
zum Verlassen eines C-Programms den Befehl exit() verwenden. 
Dies ist ein Compiler-immanenter Befehl und darf nicht mit 
dem Exit()-Befehl der DOS-Library verwechselt werden! Der 
Unterschied zwischen Exit() und exit() liegt darin, daß exit() 
ganz genau "Bescheid weiß", welche Librarys im Startup-Code 
geöffnet wurden, wieviel vom Stack verwendet wurde, und wie 
mit den Kommando-Parametern umgegangen worden ist. Diese 
Informationen fehlen dem Exit()-Befehl natürlich, so daß der 
Aufruf von Exit() zu einem totalen Systemabsturz führen 
könnte.) 

Dem exit()-Befehl kann - wie Sie oben sehen - ein Argument 
übergeben werden. Dieses Argument ist eigentlich nur dann in¬ 
teressant, wenn das Programm innerhalb eines Batches aufgeru¬ 
fen wurde. Dieser Return-Code bestimmt nämlich den weiteren 
Ablauf der Batch-Datei. Je nach FAILAT-Level wird der 
Batch-Job abgebrochen - ausgegeben wird dieser Wert allerdings 
immer. Im Include-File libraries/dos.h finden Sie einige "Exit- 
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Return“Value''-Definitionen, die Sie je nach Schwere des aufge¬ 
tretenen Fehlers verwenden sollten: 

RETURN OK (0) 

Kein Fehler auf getreten (Ende des Programms). 

RETURNJVARN (5) 

Warnung an Benutzer (z.B. Backup konnte nicht erstellt werden). 
RETURN_ERROR (10) 

Fehler (z.B. File konnte nicht geöffnet werden). 

RETURN_FAI (20) 

Schwerwiegender Fehler (z.B. Library oder Speicher konnten 
nicht geöffnet bzw. allokiert werden). 

Doch beschäftigen wir uns noch einmal mit dem von Open() 
zurückgegebenen Dateischlüssel: 

Wie Sie sicher bemerkt haben werden, wird dieser schon bei der 
Deklaration auf 0 gesetzt. Wahrscheinlich werden Sie jetzt sagen, 
daß dies recht sinnlos ist - schließlich sorgt Open() doch dafür, 
daß beim erfolglosen Öffnen einer Datei automatisch der Wert 0 
an den Dateischlüssel übergeben wird. Aber stellen Sie sich ein¬ 
mal folgende hypothetische Situation vor: 

Neben einem File werden auch mehrere Librarys geöffnet und 
Speicherblöcke allokiert. Nun stellt sich heraus, daß nicht mehr 
genügend Speicher vorhanden war. Das Programm muß also 
vorzeitig verlassen werden. Natürlich haben Sie es sich einfach 
gemacht und eine Routine geschrieben, die alles, was innerhalb 
Ihres Programms geöffnet oder allokiert wurde, wieder freigibt: 

CloseAUO 

C 

if (Memory != OL) FreeMem(Memory, ANZBYTES); 
if (GfxBase != OL) CloseLibrary(GfxBase); 
if (Datei != OL) Close(Datei); 
exi t((ULONG)RETURN_FAIL); 

> 
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Stellen Sie weiterhin sich vor, daß der Fehler vor dem Open()- 
Aufruf auftritt, und in die obige Routine verzweigt wird. Nun 
wird festgestellt, daß der Dateischlüssel ungleich 0 ist, weil die 
Variable, die die Adresse des Dateischlüssels enthält, in einem 
uninitialisierten Datenbereich liegt. Leider wird jetzt eine Datei 
geschlossen, die gar nicht geöffnet wurde - und der Systemab¬ 
sturz ist programmiert. Um dies zu vermeiden, wird schon bei 
der Deklaration aller wichtigen Variablen (Library-Basen, Spei¬ 
cher-Adressen, Dateischlüssel bzw. File-Handles) dafür gesorgt, 
daß diese auf 0 gesetzt werden. In der CloseAll()-Routine wer¬ 
den dann nur die Librarys, Speicherbereiche und File-Handles 
freigegeben, die tatsächlich allokiert bzw. angelegt wurden. 

Wie Sie aus dieser CloseAll()-Routine schon ersehen können, 
werden geöffnete Dateien durch Close() geschlossen. Sie überge¬ 
ben dem Close()-Befehl dazu einfach den von Open() erzeugten 
Dateischlüssel (bzw. die Adresse dieses Schlüssels). 

In dieser CloseAll()-Routine können Sie das Programm dann 
mittels exit() verlassen. Dazu sollten Sie wissen, daß exit() von 
jeder Stelle im Programm aus aufgerufen werden kann. 

Aber das Verlassen von Programmen ist in diesem Kapitel nicht 
das Hauptthema. Viel wichtiger ist, wie man mit Dateien um¬ 
geht. 

Nach dem öffnen einer Datei muß man schließlich Daten dort 
ablegen bzw. von dort auslesen können. 


2.5.4.2 Daten lesen und schreiben 

Zum Schreiben von Daten in eine Datei wird der Write()-Befehl 
benutzt. Diesem Befehl wird der von Open() gelieferte 
Dateischlüssel übergeben sowie die Adresse des Speicherbereichs, 
in dem die zu schreibenden Daten stehen. Damit der Write()- 
Befehl "weiß", wie viele Bytes geschrieben werden sollen, wird 
außerdem die Anzahl der zu schreibenden Bytes übergeben. 

Ein Schreibaufruf sieht also folgendermaßen aus: 
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Write (Handle, Datenbereich, AnzBytes); 

Zu beachten ist hierbei, daß die Anzahl der zu schreibenden 
Bytes als LONG-Wert angegeben werden muß. 

Weiterhin ist der Rückgabewert der Write()-Funktion zu beach¬ 
ten. Dieser Rückgabewert gibt nämlich die Anzahl der tatsäch¬ 
lich geschriebenen Bytes an. Wie Sie sich leicht denken können, 
bestehen beim Schreiben von Daten viele Fehlerquellen. Die 
unangenehmsten Fehler dürften Schreib-/Lesefehler auf der 
Diskette sein. Einen Hinweis auf diesen Fehler erhalten Sie 
durch einen Systemrequester. Auch recht häufig dürfte die Mel¬ 
dung sein, die Ihnen mitteilt, daß die Kapazität der Diskette voll 
ausgeschöpft ist. 

Wie beim Open()-Befehl müssen Sie auch beim Write()-Befehl 
auf solch einen Fehler reagieren. Feststellen, daß solch ein Feh¬ 
ler aufgetreten ist, können Sie ganz einfach daran, daß eine Dis¬ 
krepanz zwischen der Anzahl der tatsächlich geschriebenen Bytes 
(Rückgabewert von Write() vom Typ LONG) und der Angabe 
der zu schreibenden Bytes (Parameter des Write()-Aufrufs) be¬ 
steht. 


if ((Geschrieben = Write(Handle, Daten, AnzBytes)) != AnzBytes) 

C 

printf("Übertragungsfehler !!! 

Konnte nur %ld Bytes schreiben!\n". Geschrieben); 

/* exit(RETURN__ERROR) V 
/* oder CloseAUO */ 

> 

Das Lesen von Daten geschieht analog zum Schreiben. Nur daß 
hierbei ein anderer Befehl - nämlich Read() - verwendet wird. 
Ein korrekter Read()-Aufruf sähe also so aus: 

if ((Gelesen = Read(Handle, Daten, AnzBytes)) 1= AnzBytes) 
i 

printf("Übertragungsfehler !!! 

Konnte nur %ld Bytes lesen!\n". Gelesen); 

/* exit(RETURN_ERROR) */ 

/* oder CloseAUO V 

> 


Beachten sollten Sie, daß die Anzahl der zu lesenden Bytes die 
Kapazität Ihres LesePuffers nicht übersteigt. Angenommen Sie 
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haben einen Datenbereich von 1024 Bytes allokiert und wollen, 
daß dieser Bereich mit Daten aus einem File gefüllt wird. Wenn 
Sie nun den Read()-Befehl veranlassen, mehr als 1024 Bytes zu 
lesen und in diesen Speicherbereich zu schreiben, kann es pas¬ 
sieren, daß wichtige Variablen oder sogar Programmcode von 
den gelesenen Bytes überschrieben wird - was zum Pro¬ 
grammabsturz führen kann. Der Read()-Befehl hat nämlich gar 
keine Ahnung davon, wie groß der Speicherbereich ist, der die 
gelesenen Daten aufnehmen soll. 

Ebenso verhält es sich mit dem Write()-Befehl. Auch dieser 
"weiß" nicht, wie viele Daten-Bytes der angegebene Speicherbe¬ 
reich enthält. Wenn Sie also eine größere Anzahl zu schreibender 
Bytes angeben, als der tatsächlich abzuspeichernde Speicherbe¬ 
reich enthält, so werden mit Sicherheit sinnlose Daten (z.B. Va¬ 
riablen, Programmcode etc.) mit abgespeichert. 

Doch kommen wir noch einmal zur Fehlerbehandlung zurück. 
Die Tatsache, daß ein Fehler auf getreten ist, kann ja daran fest¬ 
gestellt werden, daß die Anzahl der übertragenen Bytes von der 
Anzahl der Bytes, die Sie übertragen wollten, abweicht. Aller¬ 
dings gibt dies nur Auskunft darüber, daß ein Fehler aufgetre- 
ten ist, mehr nicht. Wer mehr über den auf getretenen Fehler 
erfahren will, muß auf die IoErr()-Funktion zurückgreifen. 

Diese Funktion liefert den zuletzt aufgetretenen Fehler zurück. 
Dabei ist zu beachten, daß der Rückgabewert dieser Funktion im 
Gegensatz zur üblichen Verfahrensweise vom Type WORD ist. 
Wenn der Rückgabewert von IoErr() den Wert -1 hat, so besagt 
dies, daß kein Fehler aufgetreten ist. 

Ist der Rückgabewert von IoErr() aber größer als 0, so ist bei 
der letzten Datenübertragung ein Fehler aufgetreten. Dies trifft 
für folgende Rückgabewerte zu; 
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Open 

103 (insuffident free störe) 

Sie können nahezu beliebig viele Files öffnen. Abhängig ist die 
Anzahl der Files, die eröffnet werden können, nur von der 
Größe des noch freien Speichers. Schließlich belegt der Open()- 
Befehl Speicherplätze, um den Dateischlüssel (dessen Adresse Sie 
ja geliefert bekommen) anzulegen. Wenn hierfür nicht mehr ge¬ 
nug Speicher vorhanden ist, wird Open() abgebrochen und von 
loErrO dieser Fehler gemeldet. 

202 (object in use) 

Die Datei, die versucht wurde zu öffnen, hat schon ein anderes 
Programm eröffnet. 

206 (invalid window) 

Wie Sie vielleicht wissen, ist es mit dem Open()-Befehl auch 
möglich, Fenster zu öffnen (Open(''CON:0/0/640/256/ Win- 
dowName", (ULONG)MODE_OLDFILE);). Wenn die Parameter, 
die Sie hier angeben, dazu führen, daß das Window nicht eröff¬ 
net werden kann, erscheint dieser Fehler. 

210 (invalid stream component name) 

Der angegebene Dateiname ist ungültig. 

212 (object not of required type) 

Sie haben versucht, ein Directory zu eröffnen (Open("SYSl:c", 
(ULONG) MODE OLDFILE);). 

218 (device not mounted) 

Die angegebene Diskette (z.B. SYSl:) wurde auch nach Auffor¬ 
derung durch einen Requester nicht eingelegt. 

225 (not a DOS disk) 

Die Diskette, die man anzusprechen versucht, ist nicht im 
Amiga-Format formatiert. 
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226 (no disk in drive) 

Es ist keine Diskette im angegebenen Laufwerk eingelegt. Sie 
werden zunächst durch einen Systemrequester darauf aufmerk¬ 
sam gemacht. Wenn Sie der Aufforderung dieses Requesters, 
eine Diskette einzulegen, allerdings nicht folgen, tritt dieser 
Fehler auf. 


Read/Write 

213 (disk not validated) 

Die Diskette, auf der sich das geöffnete File befindet ist noch 
nicht vom System anerkannt worden. Dieser Fehler tritt beson¬ 
ders dann auf, wenn Sie eine Diskete aus dem Laufwerk entfer¬ 
nen, wenn die rote Kontrollampe noch leuchtet. Diese Disk-Va¬ 
lidation (Gültigmachung) ist notwendig nachdem Files geschlos¬ 
sen wurden. Nachdem nämlich Daten auf die Diskette geschrie¬ 
ben wurden, müssen disketteninterne Informationen (belegte 
Blocks usw.) erzeugt und abgespeichert werden. 

214 (disk is write protected) 

Die Diskette ist schreibgeschützt. Natürlich kann dann nicht auf 
die Diskette geschrieben werden. Das Lesen ist allerdings mög¬ 
lich. Wenn Sie nach dem Auftauchen des entsprechenden Sy- 
stemrequesters den Schreibschutz entfernen, tritt dieser Fehler 
nicht auf. Der Systemrequester verschwindet wieder, und die 
Daten werden ordnungsgemäß abgespeichert. 

221 (disk full) 

Die Diskette ist voll. Es passen keine weiteren Daten mehr auf 
die Diskette. 

223 (file is protected from writing) 

In die geöffnete Datei kann nichts hineingeschrieben werden. 

224 (file is protected from reading) 

Aus der geöffneten Datei kann nichts gelesen werden. (Diese 
beiden Fehlermeldungen (224 und 223) werden Sie allerdings 
erst ab Workbench 1.3 erhalten können.) 
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Was passiert aber, wenn Sie zunächst eine Diskrepanz zwischen 
der Anzahl der zu lesenden Bytes und der Anzahl der tatsächlich 
gelesenen Bytes fesgestellt haben, und die IoErr()-Funktion den 
Rückgabewert -1 liefert? 

Hier kann doch offensichtlich etwas nicht stimmen. Schließlich 
haben Sie einen Lesefehler festgestellt, der mit Hilfe der lo- 
Err()-Funktion näher bestimmt werden soll. IoErr() "sagt" Ihnen 
aber, daß kein Fehler aufgetreten ist. Was ist hier also los? 

Nun, Sie haben ganz einfach das Ende der Datei erreicht. Alle 
in dem File enthaltenen Daten haben Sie gelesen. 

Wie Sie also sehen, kann es gefährlich sein, sich einfach nur auf 
den Diskrepanzunterschied zur Fehlererkennung zu verlassen. 
Wird solch ein Unterschied nämlich festgestellt, wenn das File 
leergelesen wurde und dieser Unterschied dann als Fehler inter¬ 
pretiert, verlassen Sie vielleicht Ihr Programm, obwohl alles ord¬ 
nungsgemäß abgelaufen ist. 

Wenn Sie sich allerdings darauf verlassen, daß der Diskrepanz¬ 
unterschied nur beim File-Ende auftritt, kann auch dies recht 
gefährlich werdenm, weil hier dann ein aufgetretener Fehler als 
End of File interpretiert wird, und das File unvollständig gele¬ 
sen wurde. 

Das ganze verliert natürlich dann seine Gefährlichkeit, wenn 
man genau weiß, wie lang das zu lesende File ist. Als erste 
Möglichkeit, dies zu erfahren, bietet sich an, beim Abspeichern 
der Daten dafür zu sorgen, daß als allererstes die Anzahl der ab¬ 
gespeicherten Daten in das File geschrieben wird: 

ULONG Anzahl; 

if (Write(FileHandle, &Anzahl, 4L) != 4L) 
i 

/* Fehler */ 

printf("Fehlercode: %d\n",IoErr());> 

Beim Lesen können Sie dann zunächst dieses abgespeicherte 
Langwort einiesen: 
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ULONG Anzahl; 

1f (ReadCFileHatxJle, &Anzahl« 4L) != 4L> 
i 

/* hier ist auf jeden Fall ein Fehler aufgetreten */ 

/* da in dem File ja vorher die Anzahl abgespeichert */ 

/* wurde. Ein Abfrage von loErrO ist also nicht */ 

/* unbedingt notwendig und das Programm kann verlassen */ 

/* werden. */ 

> 

Das funktioniert allerdings nur dann, wenn Sie absolut sicher 
sein können, daß das zu lesende File auch in Ihrem Format - 
also mit dieser Längenangabe direkt zu Anfang - abgespeichert 
wurde. Wenn zwischendurch jemand dieses File manipuliert hat 
oder es einfach mit anderen Daten überschrieben wurde, funk¬ 
tioniert das nicht mehr. 

Es ist also auch hier geboten, nach dem Lesen den Fehlerstatus 
mit loErrO zu erfragen. 

ULONG Anzahl; 

if (ReadCFileHandle, &Anzahl, 4L) != 4L) 

if (loErrO != (W0RD)-1) 

L 

/* Tatsächlicher Fehler (nicht End of File) */ 

/* z.B. return(FALSE) */ 

> 

eise /* OK, Ende des Files */ 

/* z.B. Verlassen einer Leseroutine mit 'return(TRUE)' */ 

> 

Man kann nur in Verbindung mit IoErr() absolut sicher feststel¬ 
len, ob ein File bis zum Ende gelesen wurde oder ein Fehler 
aufgetreten ist. 


2.5.4.3 File-Informationen erfahren 

Wie kann man aber feststellen, wie lang ein File ist? Man kann 
nämlich nicht davon ausgehen, daß in allen Files eine Längenan¬ 
gabe enthalten ist. Außerdem ist solch eine zusätzliche Längen¬ 
angabe falsch. Man denke da an die IFF-Files, die universell 
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austauschbar sind und keinerlei Formatänderungen unterzogen 
werden sollten. 

Derjenige unter Ihnen, der sich ein wenig mit den IFF-Files 
auskennt, wird sich jetzt wahrscheinlich sagen, daß in den ein¬ 
zelnen Bestandteilen eines IFF-Files die Länge dieser Bestand¬ 
teile enthalten ist (Hunk-Längen). Was passiert jedoch, wenn ein 
Benutzer das gesamte IFF-File in den Speicher einiesen will, um 
es dort zu verarbeiten? 

Eine Möglichkeit, die Länge eines Files zu erhalten, ist folgende: 

ULOMG AnzByte = OL; 

BYTE Buffer; 


while (ReadCFileHandle, ÄBuffer, 1L) == IL) AnzBytes++; 

if (loErrO != (W0RD)-1) printf(»Fehler !!!\n"); 

else printf("OK\n Das File enthält %ld Bytes\n'',AnzBytes); 


Natürlich werden Sie sich sagen, daß diese Art der Längenbe¬ 
stimmung umständlich und zeitaufwendig ist. Es muß doch noch 
eine andere Möglichkeit geben, die Länge eines Files festzustel¬ 
len. Schließlich wird die Länge eines jeden Files ja auch beim 
Anzeigen des Disketteninhalts mit Hilfe des LIST-Kommandos 
angegeben. Der LIST-Befehl liest ganz bestimmt nicht jedes 
einzelne Byte eines jeden Files. Er greift auf andere Informatio¬ 
nen zurück. Aber auf welche? Hier müssen wir auf die Verwal¬ 
tung eines Files auf der Diskette zu sprechen kommen. 

Zunächst einmal muß auf der Diskette irgendwo abgespeichert 
sein, welche Files auf ihr enthalten sind. Wenn dies nicht so 
wäre, wäre eine Aufteilung des Diskettenspeicherplatzes auf 
mehrere verschiedene Dateien nicht möglich. Man hat sich je¬ 
doch nicht nur darauf beschränkt, den Namen eines Files abzu¬ 
speichern. Hier werden auch die Informationen über die Länge 
eines Files, das Erstellungsdatum sowie die Erstellungszeit und 
weitere Informationen (die Verteilung des Files auf die einzelnen 
Disketten-Sektoren) abgespeichert. 
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Um an diese Informationen eines einzelnen Files heranzukom¬ 
men, sind einige Schritte nötig: 

Zunächst einmal muß ein LCX^K auf das zu untersuchende File 
geholt werden. Dies geschieht mit der FileLock-Struktur und 
dem Lock()-Befehl: 

#include “libraries/dos.h“ 

#include "libraries/dosextens.h** 

struct FileLock *FL = OL; 


FL = (struct FileLock*) Lock(FileName, (ULONG)Access Modus); 
if (FL == OL) 
i 


> 


printfC'LOCK auf das File <%s> 

kann nicht geholt werden!!!\n",FileName); 


Beim Aufruf des Lock()-Befehls gilt es, zwei Acces_Modi - also 
Zugriffsarten - zu unterscheiden: 


ACCESS_READ (-2) 

Wenn Sie einen solchen LOCK (Zugriffsschlüssel) auf ein File 
holen, wird immer eine FileLock-Struktur erzeugt werden kön¬ 
nen - sofern das zu untersuchende File auch tatsächlich vorhan¬ 
den ist. 


Anders sieht es bei der zweiten Zugriffsart aus: 

ACCESS JVRITE (-1) 

Hier kann der Lock()-Befehl nur dann erfolgreich sein, wenn 
noch kein anderer Lock auf das File geholt wurde. Wenn Sie also 
innerhalb Ihres Programms schon den Zugriff auf dieses File 
gesichert haben, bleibt der Lock()-Befehl erfolglos. Beachten Sie 
hierbei, daß auch der Open()-Befehl mit Locks arbeitet, und 
diese erst nach dem Schließen des Files mit Close() oder bei ei¬ 
nem Neustart freigegeben werden. 

Sollten Sie sich einmal den Zugriff auf ein File mit Hilfe des 
Lock()-Befehls sichern wollen, sollten Sie unbedingt darauf 
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achten, daß dieser Zugriff nach Benutzung wieder freigegeben 
wird. Dies geschieht mit Hilfe des UnLock()-Befehls, dem ein¬ 
fach die vom Lock()-Befehl erzeugte FileLock-Struktur als Pa¬ 
rameter übergeben wird. Sollten Sie einmal vergessen, den Lock 
wieder freizugeben, so haben Sie keine Möglichkeit mehr, auf 
das File zuzugreifen. Je nach Zugriffsart läßt sich das File gar 
nicht mehr öffnen (bei ACCES_WRITE), oder man kann keine 
Daten mehr hineinschreiben (.ACCES_READ). 

Leider gibt die von Lock() erzeugte FileLock-Struktur noch 
nicht die Informationen preis, die wir eigentlich erhalten woll¬ 
ten. Um endlich an diese heranzukommen, müssen wir mit dem 
Examine()-Befehl arbeiten. 

Diesem Befehl wird die von Lock() erzeugte FileLock-Struktur 
sowie die Adresse des Speicherbereichs übergeben, der die In¬ 
formationen aufnehmen soll. 

Mit diesem Speicherbereich hat es allerdings eine besondere Be¬ 
wandtnis. Er muß an einer durch 4 teilbaren Adresse beginnen. 
Da dieser Speicherbereich auch als Struktur definiert worden ist, 
könnte man eigentlich denken, daß es reicht, diese Struktur in 
seinem Programm zu definieren: 

struct FilelnfoBlock FIB; 

Leider ist so nicht gewährleistet, daß diese Struktur an einer 
durch 4 teilbaren Adresse beginnt, obwohl das erste Element 
dieser Struktur ein Langwort ist: 


Offset 

Struktur 


struct FilelnfoBlock 

0 0x000 

v 

LONG fib DiskKey; 

4 0x004 

LONG fib_DirEntryType; /* Directory oder File */ 

8 0x008 

char fib_FilenameCl08]; 

116 0x074 

LONG fib_Protection; 

120 0x078 

LONG fib EntryType; 

124 0x07c 

LONG fib^Size; /* Größe V 

128 0x080 

LONG fib__NumBlocks; l"** vom File belgte Sektoren */ 
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132 0x084 


132 0x084 
136 0x088 
140 0x08c 


144 0x090 
260 0x104 > 


struct DateStamp fib_Date; /* Erstellungszeit V 
/* struct DateStamp 
< 

LONG ds_Days; 

LONG ds_Minute; 

LONG ds~Tick; 

> 

*/ 

char fib_Comment[116]; /* Kommentar V 


Wie Sie wissen, müssen Wörter und Langwörter nur an geraden 
Adressen beginnen. Gerade Adressen sind aber auch die Adres¬ 
sen 2, 6, 10, usw. Diese sind aber nicht durch 4 teilbar. Was ist 
also zu tun? 


Hier hilft uns der AllocMem()-Befehl der EXEC-Library weiter, 
mit dem es möglich ist, Speicherbereiche zu allokieren. Alloc- 
Mem() achtet dabei von selbst darauf, daß der allokierte 
Speicherbereich an einer durch 4 teilbaren Adresse beginnt. Wir 
brauchen also in unserem Programm nur einen Zeiger auf die 
FilelnfoBlock-Struktur zu definieren und den von dieser Struk¬ 
tur benötigten Speicher mittels AllocMem() zu allokieren: 

struct FilelnfoBlock *FIB = OL; 


if ((FIB = (struct FilelnfoBlock*) 

AllocMem(CULONG)sizeof(struct FilelnfoBlock), 
(ULONG)MEMF_CHIP)) == OL) 
i 

printf("Kein Speicher für FIB !!!\n''); 

> 

Wenn AllocMem() keinen Speicher mehr zur Verfügung stellen 
konnte, wird dem Zeiger, der auf den allokierten Speicherbe¬ 
reich zeigt, der Wert 0 übergeben. Ansonsten enthält dieser Zei¬ 
ger die Anfangsadresse des allokierten Speichers. 

Nun können wir endlich an die gewünschten Informationen 
herankommen. Wir brauchen nur noch mit Examine() die 
Fileinformationen in den FilelnfoBlock übertragen lassen und 
können diese dann auswerten. Damit Examine() auch weiß, 
welches File untersucht werden soll, muß hier auch der von 
Lock() erzeugte FileLock übergeben werden: 
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if (Examine (FL, FIB) == OL) 

{ 

printf ("Fehler bei Examine M!\n"); 

> 


Folgendes Programm wertet alle wichtigen Informationen über 
ein File aus. Neben dem File-Namen werden auch das Erstel¬ 
lungsdatum und die Erstellungszeit ausgegeben. 


#include "exec/types.h" 

#include "exec/memory.h" 

#include "libraries/dos.h" 

#include "libra ries/dosextens.h" 


struct FileLock *FL = OL; 

struct FilelnfoBlock *FIB = OL; 

VOID *Lock(); /* Diese Funktionen liefern normalerweise ULONGs */ 
VOID *AllocMem<); /* und keine Zeiger zurück. ♦/ 


ShowTime(Minute, Tick) 
ULONG Minute, Tick; 
C 


> 


printf("%02ld:%02ld:%02ld\n", Minute/60L, Minute%60L, Tick/50L); 

/* stunden, Minuten, Sekunden */ 


B(X)L Schaltjahr (Year) 

ULONG Year; 

i 

if ((((Year/4L)*4L) == Year) && 

(((Year/100L)*100L) != Year)) return((BOOL) TRUE); 
eise return((BOOL)FALSE); 

> 


ShowDate(Days) 

ULONG Days; 

r 

ULONG Year; /* Jahr V 

ULONG Month; /* Monat */ 

ULONG WochenTag; 

static char ♦DayTableCZ] = <"Sonntag", "Montag", "Dienstag", 
"Mittwoch", "Donnerstag", "Freitag", "Samstag"}; 

static char *MonthTableCl2] = {"Januar", "Februar", "März", 

"April", "Mai", "Juni", 

"Juli", "August", "September", 
"Oktober", "November", "Dezember"}; 

static ULONG DaysOfMonth[] = {31L,28L,31L, 

30L,31L,30L, 
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31L,31L,30L, 

31L,30L,31L>; 


UochenTag = Days % 7; 

Year = 1978L; 

while (Days > 366L) /* Jahr berechnen */ 

C 

if(Schaltjahr(Year)) Days -= 366L; /* Schaltjahr */ 

eise Days -= 365L; 

Year+-»-; /* ein Jahr mehr */ 

> 

if ((Days == 365L) && !SchaltJahr(Year)) Days -= 365L; 

/* noch ein Jahr übrig? */ 

if (Schaltjahr(Year)) DaysOfMonthCI] = 29L; /* Febr. updaten V 
eise DaysOfMonthCI] = 28L; 

Month = OL; 

while (Days > DaysOfMonth[Month]) 
i 

Days -= DaysOfMonth[Month]; 

Month+*»-; 

> 

/* Days enthält Monatstag */ 

Days++; /* Damit Days == OL als 1. d. Monats ausgegeben wird */ 

printf("%s, den %ld. %s im Jahre des Herrn %ld\n", 
DayTable[UochenTag], Days, 

MonthTable[Month], Year); 

> 

main(argc, argv) 
int argc; 
char *argv[]; 
i 

if (arge != 2) 

C 

printfC'AUFURF: Fileinfo FILENAME !\n'»); 
exit (10L); 

> 

if ((FL = (struct FileLock *) Lock(argv[1],(ULONG)ACCESS__READ)) 
== OL) 

C 

printfC'Das File <%s> existiert nicht !!!\n'*, argv[1]); 
exit(OL); 
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> 

if ((FIB = (struct FUelnfoBlock 

AllocMem((ULONG)sizeof(struct FileInfoBlock), 
(ULONG)MEMF_CHIP)) == OL) 
i 

pn'ntf("Kein Speicher mehr 

UnLock(FL); 

exit(IOL); 

> 

if (Examine(FL, FIB) == OL) 
i 

printfC'Fehler bei EXAMINE !M\n"); 

UnLock(FL); 

FreeHem(FIB, (ULONG)sizeof(struct FilelnfoBlock)); 
exit(IOL); 

> 

printfC'Das File enthält %ld Bytes\n", FIB->fib_Size); 
printf("Ersteilungsdatum: "); 

ShowOate(FIB->fib_Date.ds^Days); 
printf("Ersteilungszeit: "); 

ShowTime(FIB->fib_Date.ds_Minute, FIB->fib_Date.ds_Tick); 
pr i n t f ("P r o t ec t i onb i t s; ") ; 

print f("%ld\n",FIB->fib^Protection); 

if ((FIB->fib_Protection & (ULONG)FIBF^READ) > OL) 

printf("-"T; 

eise 

printf("r"); 

if ((FIB->fib_Protection & (ULONG)FIBF^WRITE) > OL) 
printf("-"); 
eise 

printfC'w"); 


if ((FIB->fib_Protection & (ULONG)FIBF^EXECUTE) > OL) 
printfC*-"); 
eise 

printfC'e"); 


if ((FIB->fib__Protection & (ULONG)FIBF_DELETE) > OL) 
printf("-\n"); 
eise 

printf("d\n"); 

UnLock(FL); 

FreeMem(FIB, (ULONG)sizeof(struct FilelnfoBlock)); 


Programm Filelnfo.c 
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Wie Sie sehen, ist die Auswertung des Datums und der Zeit 
nicht ganz so einfach, weil diese beiden Informationen in einem 
speziellen Format abgespeichert werden. In der Variable, die das 
Erstellungsdatum des Files enthält (FIB->fib_Date.ds_Days) ist 
die Anzahl der Tage abgespeichert, die seit dem 1.1.1978 ver¬ 
gangen sind. 

Ein Wert von 0 bedeutet also, daß das File am 1.1.1978 erstellt 
wurde. Bei einem Wert von 1 wurde das File am 2.1.1978 erstellt 
usw. 

Wenn wir diese Variable in ein für uns verständliches Format - 
also Wochentag, Tag.Monat.Jahr - umrechnen wollen, sind einige 
Schritte notwendig. 

Zunächst wird von der Datumsvariable solange die Anzahl der 
Tage eines Jahres (366 oder 365) abgezogen, bis die verbleiben¬ 
den Anzahl der Tage kleiner als ein Jahr ist. Dabei gilt es zu 
beachten, daß auch Schaltjahre korrekt erfaßt werden. 

Ein Schaltjahr ist ein Jahr, dessen Jahreszahl ohne Rest durch 4 
teilbar ist. Allerdings sind alle hunderter Jahre, also die Jahre 
1900, 2000, 2100 keine Schaltjahre, obwohl diese durch vier 
teilbar sind. 

Wurde das Jahr berechnet, kann daran gegangen werden, den 
Monat zu berechnen. Auch hier werden die Tage der Monate 
solange von der verbleibenden Zahl abgezogen, bis eine Sub¬ 
traktion negativ ausfallen würde (Achtung! Der Februar hat 28 
oder 29 Tage). Bei jeder Subtraktion wird hier wie bei der Be¬ 
rechnung des Jahres eine Variable hochgezählt, die den aktuellen 
Monat angibt. 

Würde die Subtraktion der Anzahl der Tage eines Monats nega¬ 
tiv ausfallen, bedeutet das, daß die noch verbleibende Anzahl 
der Tage den Monatstag angibt. Doch Vorsicht! Wenn hier der 
Wert 0 übrigbleibt, würde das ja bedeuten, daß der 0. des er- 
rechneten Monats der Monatstag ist. Dies ist aber falsch. Der 
errechnete Tag ist der erste des Monats. Deshalb muß nach die- 
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ser Berechnung der Wert 1 addiert werden, um z.B. bei einem 
Wert von 0 den Ersten des Monats zu erhalten. 

Um noch den Wochentag zu erhalten, braucht man den origina¬ 
len Datumswert (also die volle Anzahl der vergangenen Tage seit 
dem 1.1.1978) nur einer Modulodivision durch 7 zu unterziehen. 
Der hier erhaltene Wert gibt den Wochentag an. Da der 1.1.1978 
ein Sonntag war, bedeutet der Wert 0, daß der errechnete Wo¬ 
chentag ein Sonntag ist. Der Wert 6 bedeutet, daß das File an 
einem Samstag erstellt wurde. 

Die so errechneten Werte können bei der Ausgabe des Datums 
als Indizes für verschiedene String-Arrays dienen (siehe Show- 
DateO). 

Auch die Berechnung der Erstellungszeit ist ein wenig kompli¬ 
ziert. Die Erstellungszeit wird nämlich als Anzahl der vergange¬ 
nen Minuten seit Mitternacht angegeben. Die Anzahl der ver¬ 
gangenen Sekunden der aktuellen Minute wird auch angegeben - 
allerdings in Systemticks, also SOstel Sekunden. Dabei ist der 
hier angegebene Wert immer ein Vielfaches von 50. Wenn die 
"Sekundenvariable" also den Wert 250 hat, bedeutet das, daß 5 
Sekunden vergangen sind. 

Um die Anzahl der Stunden und Minuten zu erhalten, braucht 
man die "Minutenvariable" (FIB->DateStamp.ds_Minute) nur 
durch 60 zu teilen (Stunden) bzw. einer Modulodivision durch 60 
zu unterziehen (Minuten). Die Routine ShowTimeO zeigt Ihnen, 
wie einfach man die Erstellungszeit ausgeben kann. 

Unser obiges Programm kann aber noch mehr, als einfach das 
Erstellungsdatum, die Erstellungszeit angeben. Es gibt auch die 
in dem untersuchten File enthaltenen Bytes an. Dazu wird die 
Variable FIB->fib_Size herangezogen. 

Aber auch das ist noch nicht alles. Unser Programm gibt auch 
die Protection-Bits aus. Diese Bits bestimmen, was man mit ei¬ 
ner Datei bzw. einem File alles machen darf. Ist die Variable 
FIB->fib_Protection gleich 0, bedeutet das, daß das File gelesen 
(r), geschrieben (w), ausgeführt (e) und gelöscht (d) werden 
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darf. Dabei wird durch verschiedene Bits bestimmt, was mit der 
Datei geschehn darf: 

#define FIBB READ 3 /* Bitnummem */ 

#define FIBB URITE 2 
#define FIBB^EXECUTE 1 
#define FIBB_DELETE 0 

#define FI BF READ (1«FIBB READ) /* MBsken */ 

#define FIBF~WRITE (1«FIBB~URITE) 

#define FIBF“eXECUTE (1«FIBbIeXECUTE) 

#define FIBF_DELETE (1«FIBB_READ) /* Siehe "libraries/dos.h" */ 

Ist eines dieser Bits gesetzt, darf die entsprechende Operation 
nicht ausgeführt werden. Wenn es jedoch gelöscht ist, darf man 
alles mit dem File machen. 

Leider funktioniert bisher nur das DELETE-Flag. Wenn also 
dieses Bit in der Protection-Maske gesetzt ist, heißt das, daß das 
File nicht gelöscht werden darf. Auch ein Open()-Befehl - mit 
der MODE_NEWFILE-Option aufgerufen - bleibt erfolglos. 

Bleibt nun noch die Frage, was man all diesen Informationen 
anfangen kann. 

Wenn Sie mit dem Aztec-Compiler arbeiten, ist Ihnen sicher das 
Make-Untility bekannt (es wurde ja auch zu Beginn dieses Bu¬ 
ches beschrieben). Dieses Utility arbeitet aufgrund der Erstel¬ 
lungszeiten von Files. 

Wenn Make z.B. feststellt, daß das C-Cource-File eines Pro¬ 
gramms jünger als das vom Linker erzeugte Objekt-File ist, 
wird damit begonnen, das wahrscheinlich vor kurzem geänderte 
C-Source zu kompilieren. Im Anschluß daran wird dann meist 
festgestellt, daß das ablauffähige Programm älter als das Objekt- 
File ist, so daß hier das ablauffähige Programm vom Linker neu 
erzeugt wird. 

Sollten Sie das Make-Utility verwenden, müssen Sie darauf ach¬ 
ten, daß die Systemzeit immer stimmt. Nach dem Anschalten des 
Rechners ist es 00 Uhr 00 am 1.1.1978. Mit date können Sie aber 
dafür sorgen, daß die aktuelle Systemzeit korrekt gesetzt wird. 
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Daß die Systemzeit stimmt, ist für Make deshalb so wichtig, da 
bei unkorrekten Systemzeiten die Erstellungsdaten der Files 
durcheinandergeraten könnten. Stellen Sie sich vor. Sie erstellen 
ein File am 10.11.1988. Der Rechner stürzt beim Aufruf des er¬ 
zeugten Programms jedoch ab und wird neu gebootet. Wenn Sie 
nun vergessen, die richtige Zeit einzustellen und dann den C- 
Source ändern, so stellt Make fest, daß der nun geänderte C- 
Source älter als das Objekt-File und das ablauffähige Programm 
ist. Es muß - laut Make - also nicht neu compiliert werden. 
Natürlich ist das falsch, schließlich haben Sie den Fehler beho¬ 
ben und wollen, daß das neue Programm erzeugt wird. Sie sehen 
also, daß das Setzen der Systemzeit insbesondere bei Datums¬ 
und zeitabhängigen Operationen von großer Wichtigkeit ist. 

Doch haben wir weitaus mehr Informationen als nur das Erstel¬ 
lungsdatum erhalten, z.B. die Größe eines Files. Anhand dieser 
kann z.B. festgestellt werden, ob das File vollständig in den 
Speicher eingelesen werden kann, um dort bearbeitet zu werden. 
Der CLI-Editor ED geht z.B. so vor: ohne weitere Angaben stellt 
ED Ihnen 20000 Bytes Speicher für ein zu editierendes File zur 
Verfügung. Wenn Sie nun ein größeres File mit dem ED bear¬ 
beiten wollen, wird ED Sie darauf hinweisen, daß nicht soviel 
Speicher zur Verfügung steht. Sie müssen ED also "sagen", daß 
er mehr Speicher für Ihr File zur Verfügung stellen soll (z.B. ED 
File.c 30000). 

Allerdings war auch dies noch nicht alles. Der FilelnfoBlock 
enthält nämlich auch Informationen darüber, ob es sich bei dem 
mit Lock() anvisierten File-Namen wirklich um ein File oder ein 
Directory handelt. Ist die Variable FIB->fib_DirEntryType 
nämlich größer als 0, so handelt es sich hier um ein Directory! 

Wie Sie sehen, enthält die FIB-Struktur auch ein Element na¬ 
mens fib_Comment. In diesem CHAR-Array ist der sogenannte 
File-Kommentar abgespeichert. Obwohl Ihnen über das CLI mit 
dem Kommando SetComment nur 80 dieser 116 Bytes zugängig 
gemacht woprden sind, können hier bis 116 Zeichen gespeichert 
werden. Sie können hier z.B. Informationen über das File wie 
"Autor: MEIN NAME (c) ICH" abspeichern. 



174 


Das große C-Buch zum Amiga 


Weniger interessant ist die Tatsache, daß der FilelnfoBlock auch 
den File-Namen enthält. Obwohl dieser nur maximal 30 Zeichen 
enthalten darf, werden Ihnen hier 108 Zeichen (bzw. Bytes) zur 
Verfügung gestellt. 

Aber ist diese Angabe wirklich so uninteressant? Nein, natürlich 
nicht. Mit Hilfe dieser Angaben kann das DIR-Kommando 
nämlich alle Files und Unterverzeichnisse einer Diskette ange¬ 
ben: 


2.5.5 Directorys anzeigen lassen 

Dazu wird allerdings ein anderer Befehl als Examine() verwendet 
- nämlich ExNext(). Dieser Befehl ist Examine() zwar sehr ähn¬ 
lich, aber er übernimmt noch einige Vorarbeiten. Betrachten wir 
dazu einmal die FileLock-Struktur, die mit Hilfe des Lock()- 
Befehls erzeugt wird: 

Offset Struktur 

struct FileLock 
C 


0 

0x00 

BPTR fl Link; /♦ Zeiger auf nächsten Lock */ 

4 

0x04 

LONG fCkey; 

8 

0x08 

LONG fl_Access; /* Zugriffsart V 

12 

OxOc 

struct MsgPort *fl Task; 

16 

20 

0x10 
0x14 >; 

BPTR fl Volume; 


Die meisten Informationen, die diese Struktur bereithält, sind 
für uns von geringem Interesse. Das Element fl_Link jedoch 
beinhaltet eine schwerwiegende Information - nämlich die, wo 
die nächste FileLock-Struktur zu finden ist. 

Stellen Sie sich dazu alle Files und Unterdirectorys einer Dis¬ 
kette verkettet in einer einfach verketteten Liste vor. Man kann 
sich nun - ausgehend von einem beliebigen Punkt dieser Liste - 
bis zum Ende der Liste durchhangeln. Dies - und nichts anders 
- erledigt die ExNext()-Funktion. Sie ermittelt die nächste File¬ 
Lock-Struktur und führt darauf hin ExamineO aus. Nun haben 
Sie alle Informationen über das nächste File. 
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Das folgende Programm ermöglicht es Ihnen, alle nachfolgenden 
Files - ausgehend von einem, das Sie angegeben haben - auszu¬ 
geben: 

#incluGle "exec/types.h" 

#include "exec/memory.h“ 

#include "libraries/cJos.h" 

#inclucie "libraries/dosextens.h" 

VOID *AllocMem(); 

VOID *Lock(); 

VOID *CurrentDir<); 

VOID *Output(); 

struct FilelnfoBlock *FIB = OL; 
struct FileHandle *OutputFile = OL; 

BOOL Error = FALSE; 

VOID GetDIr <FL) /* Verzeichnis scannen V 
struct FileLock *FL; 

C 

if (!Error) 
i 

if (Examine(FL, FIB) == OL) /* Erst Examine, dann ExNext V 
i 

Urite(OutputFile, "Directory zerstört !\n'*, 21L); 

Error = TRUE; 
goto Endl; 

> 

while (ExNextCFL, FIB) OL) 
i 

if (FIB->fib DirEntryType > 0) /* Directory V 

i 

Write(OutputFile, " *% 6L); 

WriteCOutputFile, FIB>>fib_FileName, (ULONG) 
strlen(FIB->fib_FileName)); 

Write(OutputFile, " (dir)\n”, 7L); 

> 

eise 

i 

Write(OutputFile, *• ", 2L); /* File V 

Write(OutputFile, FIB*>fib_FileName, (ULONG) 

8trlen(FIB->fib FileName)); 

Write(OutputFile, "\n", 1L)7 

> 

> 

> 

Endl: if (FL I- OL) UnLock(FL); 

> 


main(argc, argv) 



176 


Das große C-Buch zum Amiga 


int arge; 

char *argv[]; 

< 

struct FileLock *FL = OL; 

OutputFile - OutputO; 

FL = (struct FileLock*) Lock(argv[1), (ULONG)ACCESS_READ); 
if (FL == OL) /* Lock auf Dir holen und testen */ 
exit(OL); 

> 

FIB = (struct FilelnfoBlock*) 

AllocMem((ULONG) sizeof(struct FilelnfoBlock), (ULONG) 
(MEMF_CHIPIMEMF_CLEAR)); 


if (FIB == OL) 

Urite(OutputFile, “Kein Speicher mehr lll\n“,24L); 
UnLock(FL); 

exit((ULONG)RETURN FAIL); 

> 


GetDir(FL); 


> 


if (FL != OL) UnLock(FL); 

if (FIB !- OL) FreeMem(FIB,(ULONG)sizeof(struct 
FilelnfoBlock)); 


Programm FileDir.c 


Wie Sie sehen, erfolgt der Aufruf von ExNextO mit denselben 
Übergabeparametern wie Examine(). Hat ExNext() den letzten 
File-Eintrag erreicht, sorgt ein erneuter Aufruf dieser Funktion 
für den Rückgabewert 0. Daran erkennen Sie, daß alle Files un¬ 
tersucht wurden. (ExNext() sollte übrigens erst nach einem vor¬ 
herigen ExamineO aufgerufen werden.) 

Beachten Sie, daß diesem Programm der Pfadname eines auszu¬ 
gebenden Directorys übergeben werden muß! Wenn Sie z.B. Fi- 
leDir dfO:c/RUN aufrufen, stürzt Ihr Rechner ab. (In den näch¬ 
sten beiden Unterkapiteln werden wir Ihnen jedoch ein Pro¬ 
gramm vorstellen, das alle Files - auch die in weiteren Un¬ 
terverzeichnissen enthaltenen - ausgibt und testet, ob tatsächlich 
der Pfadname zu einem Directory angegeben wurde.) 
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Wie Sie sicher festgestellt haben, ist das, was dieses Programm 
erzeugt, ein wenig anders als das, was DIR zum Vorschein 
bringt. Dies liegt aber einfach daran, daß wir die Files so ausge¬ 
ben, wie Sie auf der Diskette angelegt worden sind. Das DIR- 
Kommando sortiert alle Files und Verzeichnisse und gibt diese 
dann in alphabetischer Reihenfolge aus. Auf diesen Sortiervor¬ 
gang haben wir hier verzichtet, so daß dieses Programm ein we¬ 
nig schneller arbeitet als DIR. 

Ein kleiner Hinweis: Sicher haben Sie durch die Geräusche Ihres 
Diskettenlaufwerkes festgestellt, daß der Schreib-/Lesekopf 
recht häufig neu positioniert werden muß. Dies liegt daran, daß 
bei der Neuanlage eines Files die Informationen dieses Files ans 
Ende der Disketten-internen Liste geschrieben werden. Wenn Sie 
ein File neu anlegen, das vorher unter gleichem Namen schon 
existierte, wird die neue FIB-Struktur ans Ende der Liste gesetzt 
und die alte gelöscht. Wenn Sie dann ein weiteres File anlegen, 
wird der vorher freigewordene Bereich mit dem FilelnfoBlock 
gefüllt. 

So entsteht nach einiger Zeit ein ziemliches Durcheinander auf 
Ihrer Diskette, was umfangreiche Schreib-/Lesekopf-Positionie- 
rungen erforderlich macht. 


2.5.5.1 Directory anzeigen - inklusive aller Unterverzeichnisse, 
Wildcards und Unterbrechungen 

Sie werden jetzt sicher sagen, daß das obige Programm (File- 
Dir.c) nichts Besonderes ist. Es ist vielleicht interessant, eine 
gewisse Vorstellung davon zu bekommen, wie Files auf Diskette 
abgespeichert werden, welche Zusatzinformationen existieren 
und wie man diese auswertet. Der DIR-Befehl des CLI kann 
aber doch wesentlich mehr. So haben wir ja mit Hilfe von DIR 
opt a die Möglichkeit, alle Files eines Verzeichnisses anzeigen zu 
lassen. Hier werden auch die Files angezeigt, die sich in evt. 
vorhandenen Unterverzeichnissen befinden. 

Auch können wir mit Wildcards arbeiten. Der Aufruf DIR c#? 
sorgt Z.B. dafür, daß alle Files des aktuellen Verzeichnisses, de- 
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ren erster Buchstabe das c, bzw. C ist (Groß- und Kleinschrei¬ 
bung haben hier keinen Einfluß !), ausgegeben werden. Oder z.B 
Dir c?. Hier werden z.B. alle zweibuchstabigen Files ausgegeben, 
die mit c beginnen. Ausgegeben werden hier z.B. cd, cc usw. 
Anders gesagt: Wir können beliebige Buchstaben durch ein ? er¬ 
setzen (Joker), und beliebige Zeichenketten (auch leere) durch 
#? (Wildcard). 

Was beim DIR-Kommando auch recht angenehm auffällt, ist die 
Tatsache, daß man die Abarbeitung des Befehls durch Ctrl-C 
unterbrechen kann. Auch dies ist bei unserem Programm FileDir 
nicht möglich. 

So stellen sich uns also drei Probleme: 

Problem 1: 

Wie werden alle Files - auch die in anderen Unterverzeicnissen 
ausgegeben? 

Problem 2: 

Wie programmiert man die Ausgabe der File-Namen in Abhän¬ 
gigkeit von Patterns (Strings, die Wildcards und Joker enthal¬ 
ten)? 

Problem 3; 

Wie erreicht man, daß ein Programm durch Ctrl-C abgebrochen 
wird? 


Zu Problem 1: Pfadangaben 

Die Untersuchung aller Unterverzeichnisse einer Diskette erweist 
sich leider als nicht so einfach, wie der eine oder andere unter 
Ihnen denken könnte. Die Ausgabe aller Files beruht zwar auf 
einem rekursiven Algorithmus, aber es reicht leider nicht, die 
Routine, die die Files ausgibt (wir nennen sie von nun an Get- 
Dir(), siehe FileDir), beim Feststellen, daß der Name eines Un- 
terverzeichnises ausgegeben werden soll, sich einfach selbst wie¬ 
der aufrufen zu lassen. 
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Wenn wir also entdeckt haben, daß wir gerade den Namen eines 
Unterverzeichnisses ausgeben, müssen wir uns auf dieses Unter¬ 
verzeichnis einen neuen Lock holen, weil erst dann auf die in 
diesem Verzeichnis enthaltenen Files zugegriffen werden kann. 
Dazu ist aber der Pfadname notwendig. Angenommen, Sie be¬ 
finden sich im Verzeichniss dfOrinclude und treffen bei der 
Ausgabe nun auf das Verzeichnis exec. Wenn Sie die in diesem 
Verzeichnis enthaltenen Files ausgeben wollen, müssen Sie sich 
einen Lock auf das Verzeichnis exec holen. Was passiert aber, 
wenn sich innerhalb dieses Unterverzeichnisses noch weitere 
Verzeichnisse befinden? Um die Files dieser Verzeichnisse aus¬ 
zugeben müssen Sie also wieder einen Lock auf das auszuge¬ 
bende Verzeichnis holen. Da Sie sich aber immer noch im Ver¬ 
zeichnis dfO:include befinden, müssen Sie hier dem Lock()-Be- 
fehl z.B. schon den Pfadnamen exec/exec_weitere angeben. Sie 
müssen also immer dafür sorgen, daß der Pfadname aufgearbei- 
tet wird. 

In bezug auf eventuelle spätere Erweiterungen des DIR-Befehls 
(eingebaute Delete- und Rename-Funktionen, die Sie, wenn Sie 
Lust haben, selbst entwickeln können) wollen wir dafür sorgen, 
daß uns immer der vollständige Pfadname eines auszugebenden 
Files bekannt ist. Dies erfordert allerdings ein wenig Rechnerei 
mit Strings. 

Auch muß schon zu Beginn der Pfadname erzeugt werden. Dazu 
ein Beispiel: Sie befinden sich wieder im Verzeichnis 
dfOiinclude. Um die in diesem Verzeichnis enthaltenen Files aus¬ 
geben zu lassen, brauchen Sie bekanntlich nicht DIR dfO:include 
aufzurufen. Es reicht der einfache Aufruf von DIR, der die Fi¬ 
les des aktuellen Verzeichnisses ausgibt (hier eben dfO:include). 
Auch unser Programm soll so komfortabel sein. 

Dazu ist es aber unbedingt notwendig, auch beim Aufruf unseres 
Programms ohne Pfadangaben (DIR), den Pfadnamen des gerade 
aktuellen Verzeichnisses zu ermitteln. 

Wenn wir diesen Pfadnamen ermittelt haben, müssen wir immer 
dann, wenn wir die Files eines Unterverzeichnisses ausgeben 
wollen, veranlassen, daß dieser Pfadname um den Namen des 
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auszugebenden Unterverzeichnisses erweitert wird. Nach der 
Ausgabe der Files muß der Name des Unterverzeichnisses wieder 
entfernt werden. 

Sie werden sich sicher schon denken können, daß der String, der 
den Pfadnamen enthalten soll, ein globaler String ist. Auch wer¬ 
den wir eine globale Variable einföhren müssen, die uns immer 
mitteilt, an welcher Stelle der letzte Buchstabe in diesem String 
bzw. CHAR-Array steht. Damit wir nach der Ausgabe der Un¬ 
terverzeichnis-Files den Namen des jeweiligen Unterverzeich¬ 
nisses wieder entfernen können, müssen wir eine Variable zur 
Verfügung stellen, die uns Auskunft darüber gibt, wie viele 
Buchstaben zum alten Pfadnamen hinzugekommen sind. Diese 
Variable muß natürlich lokal sein - also bei jedem Rekursions¬ 
aufruf neu angelegt werden. 

Wenn bei der Ausgabe des Directorys also auf ein Unterver¬ 
zeichnis gestoßen wird, das ausgegeben werden soll, so muß man 
den globalen Pfadnamen-String um den Namen des auszugeben¬ 
den Unterverzeichnisses erweitern. Nachdem das Unterverzeich¬ 
nis ausgegeben wurde, wird der vorher zugefügte Name wieder 
entfernt. 


Zu Problem 2: Wildcards und Joker 

Es ist mitunter sehr sinnvoll, eine Selektion der auszugebenden 
Files und Unterverzeichnisse zu treffen. Was ist z.B., wenn alle 
C-Programm-Sources aufgelistet werden sollen? Mit dem obigen 
Programm (FileDir) kann man nur alle Files eines Verzeichnisses 
anzeigen lassen. 

Um solch eine Selektion vornehmen zu können, müssen wir also 
dafür sorgen, daß die File-Namen vor der Ausgabe untersucht 
werden, ob Sie auch ausgegeben werden sollen. 

Wie wird aber erkannt, ob ein File-Name ausgegeben werden 
soll oder nicht? Zunächst einmal muß der String definiert wer¬ 
den, der bestimmt, nach welchem Muster (engl. Pattern) die Fi¬ 
les ausgegeben werden sollen. Wenn dieser bekannt ist, können 
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die File-Namen darauf untersucht werden, ob sie auf das ange¬ 
gebene Pattern passen oder nicht. 

Ein solcher Pattern-String kann folgende "Zeichen" enthalten: 

#? steht für beliebige Zeichenketten 

? steht für einen beliebigen Buchstaben. 

Um z.b; alle C-Sources auszugeben, muß das Pattern #?.c ange¬ 
geben werden. Bei der Ausgabe der File-Namen werden nur die 
Files berücksichtigt, die am Ende die Buchstabenkombination .c 
enthalten. 

Um z.B. nur die Files Tempi.c, Temp2.c, ..., Temp9.c auszuge¬ 
ben, muß nur das Pattern Temp?.c angegeben werden. 

Doch betrachten wir einmal, wie man vergehen muß, um diese 
Wildcards zu programmieren: 

Nehmen wir an, daß der Wildcard-String folgendes Aussehen 
hat: 


c#?b?.c 

übersetzt für die Ausgabe des Directorys bedeutet dieser String: 

Gib alle File-Namen aus, die mit einem c beginnen, auf 
das ein beliebiger String (auch ein leerer String) folgt, auf 
den wiederum der Buchstabe b folgt, der wiederum von 
einem beliebigen Buchstaben und der Kombination .c ge¬ 
folgt wird. 

Um nun festzustellen, ob ein File-Name auf dieses Pattern paßt, 
muß der Wildcard-String nach folgenden Schema untersucl^t 
werden: 

1. Ist das aktuelle Zeichen ein Fragezeichen? 

2. Wenn ja, ignoriere das aktuelle Zeichen des File-Namens. 
Gehe zu 1. 

3. Wenn Nein: Ist ein Wildcard #? das aktuelle Zeichen? 
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4. Wenn Ja: Ermittle den String, der zwischen dem aktuellen 
und einem evt. folgenden Wildcard steht, und suche nach 
diesem String. Wenn dieser String nicht gefunden werden 
konnte, erfüllt der File-Name nicht die Wildcard-Bedin¬ 
gungen. Wenn der String gefunden wurde, gehe zu 1. 

5. Wenn das Zeichen nicht der Joker oder ein Wildcard ist, 
vergleiche das aktuelle Zeichen des Wildcard-Strings mit 
dem aktuellen Zeichen des File-Namens. Wenn beide 
gleich sind, gehe zu 1. Wenn nicht, paßt der File-Name 
nicht auf das Pattern. 

Diese Schritte werden solange ausgeführt, bis entweder festge¬ 
stellt wurde, daß der File-Name nicht auf das Pattern paßt, oder 
einer bzw. beide Strings vollständig abgearbeitet wurden. 


Zu Problem 3: CtrI-C abfragen 

Kommen wir nach den Wildcards zu dem Abfangen von Ctrl-C. 
Nach dem Betätigen dieser Tastenkombination muß das Pro¬ 
gramm beendet werden. Das Feststellen dieser Tastenkombina¬ 
tion geht recht einfach vonstatten. Dazu müssen wir nur das Si¬ 
gnal-System der Amiga-Tasks für unsere Zwecke ausnutzen. 

Wie Sie vielleicht wissen, werden zur Kommunikation zwischen 
Tasks sogenannte Signale verwendet, die dem Empfänger-Task 
mitteilen, was für eine Nachricht an ihn gesandt wurde. 

Normalerweise wird beim Feststellen, daß ein Signal gesetzt 
wurde, eine Nachricht abgeholt. Dies ist bei der Abfrage von 
Ctrl-C allerdings nicht notwendig. 

Hier reicht es, einfach nur festzustellen, ob ein bestimmtes Si¬ 
gnal gesetzt wurde. Derjenige unter Ihnen, der sich ein wenig 
mit Tasks und Signalen auskennt, wird jetzt sicher fragen, woher 
wir wissen, welches der 32 Signale, die zur Verfügung stehen, 
benutzt wird. Nun, das ist recht einfach, denn die Signale 0 bis 
15 werden vom System festgelegt. Diese Signale haben also im¬ 
mer dieselbe Bedeutung, während die Signale 16 bis 31 vom Be¬ 
nutzer ihre Bedeutung zugewiesen bekommen. 
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Wenn also Ctrl-C gedrückt wurde, wird an den Task der gerade 
abläuft, das Signal mit der Nummer 12 gesendet. 

Wie stellt man aber fest, welches Signal gesendet wurde? Nun, 
dazu greifen wir auf eine Routine zurück, die eigentlich dazu 
gedacht ist, die aktuellen Signale zu verändern: 

Altesignale » SetSignaUNeueSignale, Maske); 

Diese Routine überträgt den Zustand von NeueSignale in die 
Taskstruktur - allerdings nur dann, wenn auch in Maske das je¬ 
weilige Bit gesetzt ist. Um z.B. das Signal mit der Nummer 0 zu 
setzen, muß sowohl Bit 0 in NeueSignale als auch in Maske ge¬ 
setzt sein. Um das Signal 0 zu löschen, muß das Bit 0 in NeueSi¬ 
gnale gelöscht, in Maske aber gesetzt sein. Der Rückgabewert 
dieser Funktion schließlich gibt den Zustand der Signale vor 
dieser Veränderung zurück. 

Um den Zustand der Signale zu erhalten, ohne diese zu verän¬ 
dern, müssen wir SetSignal() nur wie folgt aufrufen: 

AktuelleSignale - SetSignaUOL, OL); 

Um nun festzustellen, ob Ctrl-C gedrückt wurde, muß nur das 
Bit 12 untersucht werden. Ist es gesetzt, wurde Ctrl-C gedrückt: 

#define SIG CTRL CB 12L /* Bitnuimer •/ 

#define SIG”cTRL“c (1«12L) 


AktuelleSignale = SetSignaUOL, OL); 

if ((AktuelleSignale & SIG CTRL_C) == SIG CTRL C) 

L 

/* BREAK */ 

> 

Vor der Ausgabe eines File-Namens brauchen wir also nur zu 
testen, ob Ctrl-C gedrückt wurde, und müssen dann das Pro¬ 
gramm verlassen. 

Da die Ausgabe der File-Namen aber rekursiv sein kann (wenn 
alle Unter-Directorys ausgegeben werden), können wir das Pro- 
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gramm nicht einfach mit exit(10L) o.ä. verlassen, da so Speicher, 
der für die FIBs allokiert wurde, verloren geht. Deshalb wird 
beim Erkennen von Ctrl-C eine Fehlervariable gesetzt und ans 
Ende der Ausgaberoutine gesprungen. Hier wird dafür gesorgt, 
daß die Speicherplätze wieder freigegeben werden. 

Wenn während eines Rekursionsaufrufes Ctrl-C gedrückt wird 
(oder ein Fehler auftritt, was durch den gleichen Mechanismus 
zum Programmabbruch führt), wird dies nach dem rekursiven 
Aufruf der Funktion anhand der globalen Fehlervariablen fest¬ 
gestellt. 

Da sich dies alles ein wenig verwirrend anhört, wollen wir Ihnen 
nun das Listing des Directory-Befehls zeigen, der mit Directory 
[Verzeichnis] [-a] aufgerufen wird. 

#inclucle **exec/types.h“ 

#include "exec/memory.h” 

#include "libraries/dos.h” 

#i nc lude •• l i brari es/dosextens. h” 

VOID *Lock(); 

VOID *AUocMem(); 

VOID *ParentDir<); 

VOID *Open(); 

VOID ♦OutputO; 

struct FileHandle *OutputFile = OL; 

/* Für Ausgabe */ 

char PathC256]; I* Enthält vollständigen Path-Namen V 

ULONG GlobalPos = OL; i* Enthält akt. Position in Path-String V 
BOOL Error = (BOOL) FALSE; /* Globale Fehlervariable V 
ULONG Verschachtellung = ql; /* muß Global sein, da diese Variable V 

innerhalb der rekursiven Funktion V 
/♦ GetOirO benutzt wird, und dort die V 
/♦ aktuelle Verschachtellungstiefe der V 
i* Directorys angibt. . V 

char UildcardStringllOO]; /* Dieses Array enthält den UiIdcard-String V 

/♦extrahiert aus Kommando-Parameter. V 

#define SIG_CTRL CB 12L /* Bitnummer V 

#define SIG^CTRlIc (1«12L) /* Maske V 

BOOL CTRL CO 
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/* Beim Betätigen von Ctrl-C wird an den Task das Signal V 
/♦ Nummer 12 gesandt (siehe #defines). V 


if ((SetSignal(0L,0L) & SIG CTRL_C) == SIG_CTRL_C) 
return(TRUE); 
eise 

return(FALSE); 


GetUiIdcardString(Name) 
char *Naine; 

C 

int i; 

int Len = 0; 

BOOL UiIdcardFound = FALSE; 
i = strlen(Name); 

while((NameCi] != *:■) && (NameCi] != '/') && (i>=0)) 
i 

Len++; Länge des Wildcard-Strings V 

if (NameCi--] == *?*) WiIdcardFound = TRUE; 

> 

/* Suche von hinten nach vorne, ob Uildcard oder Joker V 
/* enthalten ist. (Es braucht nur nach einem ? gesucht V 
/* werden, da dieses Zeichen Bestandteil beider ist) V 
/* Wenn kein Wildcard oder Joker gefunden wird, ist V 
/* der Teil vor : oder / Directoryname. */ 

if (WiIdcardFound) 

C 

i = strlen(Name); 

while(Len > 0) 
i 

WiIdcardString[Len-1] = NameCi--]; 

Len--; 

> 

NameCi+1] = *\000*; 

> 

eise 

< 

WiIdcardString CO] = *#*; 

WiIdcardString [1] = *?*; 

WiIdcardString[2] = *\000*; 

> 

> 

/* Such-String für Wildcard ermitteln */ 
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GetSearchStringCPattern, SearchString) 
char *Pattern,*SearchString; 

< 

int i = 0; 
int j = 0; 

while((Pattern[i] != (char)O) && 

(PatternCi] != (char)»#') && 

(PatternCi] != (char)*?')) 

/* Bis zu nächsten Uildcard suchen */ 

SearchStringCj++] = Pattern[i++]; 

SearchString[j] = (char)O; 

> 

/* Nach Such-String suchen V 

BCX)L Search(Original, Searchlt) 
char *Original,*SearchIt; 

int i = 0; /* Suche im original String nach */ 

int j; /* ermitteltem Such-String. */ 

whileCOriginalCi] != (char)O) 

if(Original Ci] == SearchltCO]) /* erstes Zeichen gefunden V 
i 

j=0; /* Stimmt Rest des Strings ? V 

while(SearchItCj] !=(char)0) 

C 

if ((OriginalCi++]jOxZO) != 

(SearchltCj++]jOxZO)) 
return((BOOL)FALSE); 

> 

return((BOOL)TRUE); 

> 

eise i++; 

> 

return((BOOL)FALSE); 

> 

/* Paßt Pattern (#?, ?) auf String ? */ 

BOOL Wildcard(Pattern, Match) 

char *Pattern,*Match; /* Pattern: Wildcard String */ 

/* Match: String der untersucht werden 

soll */ 

/* ob er auf Pattern -|passt-| 

*/ 

i 

int i = 0; 
int j = 0; 
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char SearchStringC256]; 
BOOL Longer; 


while (PatternCi] != (char) 0) 

C 

if ((PatternCi] == *#') && (Pattern[i+1] == '?*)) 

/* Uildcard universal gefunden */ 

C 

if (Match[j] == (char) 0) return((BOOL) TRUE); 

/* Ende des Match- V 

i+=2; /* Wildcard überlesen */ 

GetSearchString(&Pattern[i]^SearchString); 

if (SearchStringCO] t= (char)O) /* Leerer SearchString */ 
if (Search(&MatchCj],SearchString) » (BOOL)FALSE) 

return((BOOL)FALSE); /* Search-String nicht gefundeni */ 

i += strlen(SearchString); 

/* Ab gefundenem Search-String weitermachen */ 
j += strlen(SearchString); 

Longer = FALSE; 

> 

eise 

if (PatternCi] == *?*) 

/* Uildcard one shot (Joker) gefunden */ 
i 

if (MatchCj] == (char) 0) return((BOOL) FALSE); 

/* Ende des Match- */ 
i*»'+; /* Strings ? V 

j*^+; 

if (MatchCj] != (char)O) Longer = TRUE; 

/* Nach ? folgt noch ein Zeichen */ 

eise Longer = FALSE; 


> 


if (MatchCj+1] != (char)O) Longer = TRUE; 

> 

eise 

if ((PatternCi++] |0x20) != (Match(]♦■►] 10x20)) 

/* KLEINBUCHSTABEN V 


return((BOOL)FALSE); 
eise Longer = FALSE; 


return((BOOL)!Longer); 

> 


BOOL Directory(DirName) 
char *DirName; 

L 

struct FileLock *FL = OL; 

struct FilelnfoBlock *FIB * OL; 


BOOL Result - TRUE; 
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FL = (struct FileLock*) LockCDirMame, (ULONG)ACCESS_READ); 

if (FL == OL) /* Lock auf Dir holen und testen */ 
i 

Write(OutputFi le, “Wrong path !! !\n*',16L); 

Result = FALSE; 
goto DirEnd2; 

> 

FIB = (struct FilelnfoBlock*) 

AUocMe(n((ULONG) sizeof(struct Fi lelnfoBlock), (ULONG) 
(MEMF_CHIP|MEMF_CLEAR)); 

if (FIB == OL) 

C 

Write(OutputFile, “Kein Speicher mehr !!!\n“, 23L); 
Result = FALSE; 
goto DirEnd2; 

> 

if (Examine(FL, FIB) == OL) 

< 

Write(OutputFile, “Directory zerstört !\n“, 21L); 

Result - FALSE; 
goto DirEnd2; 

> 

if (FIB->fib DirEntryType <= OL) 
i 

Write (OutputFile,. “Achtung! Kein Directory!\n“, 26L); 
Result = FALSE; 

> 


DirEnd2: 

if (FIB != OL) FreeMem(FIB,(ULONG)sizeof(struct FilelnfoBlock)); 
DirEndl: 

if (FL != OL) UnLock(FL); 
return (Result); 

> 


/* Strings der Verzeichnisse aneinanderhängen, und V 
/* in dem String Path abspeichern. V 

Concat(String, FL) 
char *String; 
struct FileLock 


ULONG LocalPos = OL; 


/* Position im anzuhängenden String V 
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while (Path[GlobalPos++]=String[LocalPos++]); /* Kopieren */ 

/* Die Variable GlobalPos zeigt auf das */ 

/* String-Endzeichen (\000) des Path-Strings */ 

/* Je nach Verzeichnisstufe (Hauptverzeichnis (z.B. SYS1:) */ 
/* Unterverzeichnis (z.B. include/) die Zeichen bzw. / */ 
/* zwischensetzen */ 


switch ((ULONG)FL) 
case OL: 

Path[--GlobalPos]=*:‘; 

Path[++GlobalPos]=(BYTE)0; 
break; 


/* Hauptverzeichnis erreicht */ 
/* String-Ende V 


default: 

Path[--GlobalPos]=‘/'; /* Unterverzeichnis erreicht */ 
Path[++GlobalPos]=(BYTE)0; /* String-Ende */ 
break; 

> 

> 


VOID GetBackPath (FL) 
struct FileLock *FL; 
i 

struct FilelnfoBlock *FIB = OL; 
struct FileLock *TL = OL; 
struct FileLock *(11 = OL; 


if (»Error) /* Noch kein Fehler */ 

C /* Diese Routine ist REKURSIV ! */ 

FIB = (struct FilelnfoBlock*) 

AllocMem((ULONG) sizeof(struct FilelnfoBlock), 

(ULONG) MEMF_CHIPjMEMF__CLEAR); 

/* Muß jedesmal neu allokiert werden, da im FIB ja der jeweilige 

*/ 

/* Verzeichnisnamenthalten ist. 

*/ 

if (FIB == OL) 
i 

Write(OutputFile, "Kein Speicher mehr !!!\n",18L); 

Error = TRUE; /* Global Error */ 
goto BackEnd; 

> 

TL = (struct FileLock*)ParentDir(FL); 


/* Lock auf übergeordnetes Verzeichnis holen */ 
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/* Wenn TL != 0 ist, ist das Hauptverzeichnis noch nicht erreicht. V 
/* In diesem Fall wird GetBackPathO solange Rekursiv aufgerufen, V 
/* bis das Hauptverzeichnis erreicht wurde. Dann werden vom Haupt- V 
/* Verzeichnis ausgehend alle Strings aneinandergehängt V 

/* (z.B: SYS1 + *:* + include + */' + exec + */*). V 

if (TL != OL) 

C 

GetBackPath(TL); 

GL = (struct FileLock*) ParentDir(TL); 

/* Jetzt übergeordnetes Verzeichnis erreicht ? V 

if (Examine(TL, FIB) == OL) 
i 

WriteCOutputFile, “Directory zerstört !\n'*,21L); 
goto BackEnd; 

> 

Concat<FIB->fib_FileName, GL); 

/* Wenn Hauptverzeichnis erreicht wurde, gibt ParentDirO */ 
/* den Wert OL zurück. Dann wird bei ConcatO das Zeichen V 
/* : zwischen die anzuhängenden Strings gesetzt. V 

UnLock(GL); 

GL = OL; 

> 

/* eise Hauptverzeichnis erreicht V 

> 

BackEnd: 

if (GL != OL) UnLock (GL); 
if (TL != OL) UnLock (TL); 

if (FIB != OL) FreeMem(FIB,(ULONG)sizeof(struct FilelnfoBlock)); 

> 

GetWholePath (Name) 
char *Name; 

< 

struct FileLock *FL = OL; 
struct FileLock *PL = OL; 
struct FilelnfoBlock *FIB = OL; 


FIB = (struct FilelnfoBlock*) 

AllocMem((ULONG) sizeof(struct FilelnfoBlock), 
(ULONG) MEMF_CHIP|MEMF_CLEAR); 

/* FIB allokieren */ 


if (FIB == OL) 
i 
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Urite(OutputFile, "Kein Speicher mehr !!!\n",18L); 

Error = TRUE; /* Globale Fehlervariable */ 

goto UholeEnd; 

> 

FL = (struct FileLock*) Lock(Name,(ULONG>ACCESS_READ); 

/* Lock auf angegebenes Verzeichnis holen V 

if (Examine(FL,FIB) == OL) 

C 

Write (OutputFile, "Directory zerstört !\n",21L); 

Error = TRUE; 
goto WholeEnd; 

> 

if CFIB“>fib DirEntryType==OL) Kein Directory !!!! V 

< 

Urite(OutputFile, Name, (ULONG)strlen(Name)); 

WriteC ist ein File und kein Verzeichnis !!!\n", 40L); 

Error = TRUE; 
goto WholeEnd; 

> 

GetBackPath(FL); 

if (Error) /* Fehler aufgetreten ? */ 

goto WholeEnd; /♦ ja V 

/* In GetBackPathO wurde der Name des angegebenen Verzeichnisses */ 
/* nicht an Path angehangen. Dies wird hier nachgeholt. */ 

/* Zur Erinnerung: Im FIB steht z.B. nur der Name "exec", obwohl */ 
/♦ "inclüde/exec" angegeben wurde. */ 

PL = ParentDir(FL); 

Concat(FIB“>fib_FileName, PL); Pfadnamen vervollständigen V 
UnLock(PL); 

PL = OL; 

WholeEnd: 

if (FL != OL) UnLock(FL); 

if (FIB != OL) FreeHem(FIB,(ULONG)sizeof(struct FilelnfoBlock)); 


VOID GetDir(DirName, All) 
char *DirName; 

BOOL All; 

C 

struct FilelnfoBlock *FIB = OL, 

struct FileLock *FL = OL, 

struct FileLock *TL » OL, 

ULONG LocalPos; 
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ULONG i; 

ULONG Len = OL; !* Länge des File-Namens V 

if (!Error) 

< /* Im Fehlerfall, oder nach Ctrl-C nur noch belegte Speicher */ 

/* freigeben. V 

FL = (struct FileLock*) Lock(DirName, (ULONG)ACCESS_READ); 

if (FL == OL) /* Lock auf Dir holen und testen V 

Write(OutputFile, "Wrong path !!!\n”,16L); 

Error = TRUE; 
goto End2; 

> 

FIB = (struct FilelnfoBlock*) 

AllocHem((ULONG) sizeof(struct FilelnfoBlock), (ULONG) 
(MEMF^CH IPI MEMF__CLEAR ) ) ; 

if (FIB == OL) 

< 

Write(OutputFile, "Kein Speicher mehr n!\n", 23L); 

Error = TRUE; 
goto End2; 

> 

if (Examine(FL, FIB) == OL) 

L 

Urite(OutputFile, "Directory zerstört !\n", 21L); 

Error = TRUE; 
goto End2; 

> 


while (ExNext(FL, FIB) != OL) 

if (Wildcard(UiIdcardString, FIB->fib_FileName)) 
C 

if (CTRL CO) 

C 

Write(OutputFile, "**♦ BREAK ***\n", UL); 
Error = TRUE; 
goto End2; 


for (i=0L;i<Verschachtellung;i^^) 

Write(OutputFile, " ", 6L); 

if (FIB->fib DirEntryType > 0) /* Directory V 

C 

Write(OutputFile, " ", 6L); 

Write(OutputFile, FIB->fib_FileName, 

(ULONG)strlen(FIB->fib_FileName)); 
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Write(OutputFi le, •* (dir)\n", 7L); 

if (AU) 
i 

/* Inhalt eines weiteren Directory ausgeben */ 

/* Dazu wird der Name des Directorys an den */ 

/* von GetBackPathO erzeugten Pathnamen */ 

/* angehangen. */ 

LocalPos = OL; 

while (PathCGlobalPos-t**»*] = 

FlB->f ib_Fi leNameCLocalPos’*-'*-] ); 

/* Anhängen */ 

Path[--GlobalPos]=(char)'/*; 

Path [**”»*GlobalPos)=(char)0; 

/* Das Zeichen / anhängen, und String beenden */ 
Verschachtellung++; 

GetDir(Path,All); 

/* REKURSION V 

if (Error) /* Fehler */ 

goto End2; 

Verschachtellung--; 

/* Keine Weiterbearbeitung nach Fehler oder Abbruch V 

GlobalPos -= LocalPos; 

/* vorher angehangenen Namen */ 

/* entfernen, bzw. GlobalPos */ 

/♦ updaten, und \000 setzen */ 

Path[GlobalPos] = (char)O; 

> 

> 

eise 

i 

Len = (ULONG)strlen(FIB->fib_FileName); 

Write(OutputFile, " «, 2L); 

Write(OutputFile, FIB->fib_FileName, Len); 
Write(OutputFile, **\n”, 1L); 

> 

> 

> 

> 

End2: if (FIB != OL) FreeMem(FIB,(ULONG)sizeof(struct FilelnfoBlock)); 

Endl: if (FL != OL) UnLock(FL); 
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> 


main(argc, argv) 
int arge; 
char *argvC]; 
i 

int i; 

char *Pfadname = *'\000”; 

BOOL ALL = FALSE; 

for (i=1;i<argc;i++) 

C 

if (argvCiiCO] != »-*) 

C 

Pfadname = argv[i]; 

> 

eise 

switch(argvCi] [1]) 

C 

case 'a*: 

ALL = TRUE; 
break; 

default: 

printf("Unbekannte Option <%s> !\n",argvCi]); 
exit(OL); 

> 

> 


OutputFile = (struct FileHandle *) OutputO; 

GetWiIdcardString(Pfadname); 

if (Directory(Pfadname)) 

C 

GetWholePath(Pfadname); /* gesamten Pfad ermitteln */ 

GetDir(Path,(BOOL)ALL); /* Directory ausgeben */ 

> 

> 


Programm Directory.c 


Erläuterungen zu obigem Programm 

In main() wird zunächst einmal festgestellt, ob beim Aufruf die 
Option -a angegeben wurde. Ist dies der Fall, wird die Variable 
ALL auf TRUE gesetzt, was dafür sorgt, daß alle Unterver¬ 
zeichnisse ausgegeben werden. 
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Dann wird mit der Funktion Output() der Ausgabekanal ermit¬ 
telt. Diesen Ausgabekanal kann man wie ein mit Open() geöff¬ 
netes File behandeln. Im Gegensatz zu printf() kann die Ausgabe 
über diesen Ausgabekanal nicht unterbrochen werden. 

Wie Sie vielleicht festgestellt haben, führt die Tastenkombination 
Ctrl-C während der Ausgabe eines Textes mit printf() zum Pro¬ 
grammabbruch. Dies wollen wir aber vermeiden, da so die von 
uns belegten Speicherplätze verloren gehen. Wir fragen ja des¬ 
halb selber die Tastenkombination Ctrl-C ab, um die belegten 
Speicherplätze freigeben zu können. 

Danach wird die Routine GetWildcardString() aufgerufen. Diese 
Routine sorgt dafür, daß eine Wildcardangabe von den Pfadan¬ 
gaben des auszugebenden Unterverzeichnisses getrennt werden. 
Wenn Sie z.B. Directory dfO:include/ex#? auf rufen, würde 
theoretisch ja versucht, das Verzeichnis dfO:include/ex#? auszu¬ 
geben. Dieses existiert aber gar nicht. Ausgegeben werden soll 
das Verzeichnis dfO:include/. ex#? ist nur das Pattern (Muster), 
nach dem die File-Namen ausgegeben werden sollen. GetWild- 
cardStringO geht bei der Trennung von Pfadangaben und Wild- 
card-String so vor sich; 

Der String (z.B. dfO:include/ex#?) wird von hinten nach vorne 
nach dem Vorkommen von ? durchsucht. Dieses Zeichen ist ja 
Bestandteil von Wildcard(#?) und Joker (?). Es wird allerdings 
nur solange gesucht, bis das Zeichen / oder :, oder der Anfang 
des Strings gefunden wurde. Wurde das Vorkommen des ? fest¬ 
gestellt, so stellt der hintere Teil des Strings bis zum erstmaligen 
Auftauchen von / oder : den Wildcard-String dar. Dieser wird 
als globaler String verwaltet. Auch der Pfadname wird von die¬ 
ser Routine bearbeitet. Nach dem Bestimmen und Kopieren des 
Wildcard-Strings wird dieser aus dem der Routine GetWildcard- 
StringO übergebenen String entfernt. Dazu wird einfach das er¬ 
ste Zeichen des gefundenen Wildcard-Strings durch das String- 
Endezeichen \000 ersetzt. 

Nach der Ermittlung von Wildcard-String und Pfadname kann 
nun daran gegangen werden, das Directory auszugeben. Dazu 
wird erst einmal geprüft, ob der angegebene Pfadname tatsäch- 
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lieh der Pfadname zu einem Directory ist (DirectoryO). Ist dies 
nicht der Fall, wird das Programm verlassen. 

Wenn aber der angegebene Pfadname zu einem Directory gehört, 
wird erst einmal dafür gesorgt, daß der Pfadname auf gearbeitet 
wird (GetBackPathO). Dazu wird ein Lock auf das angegebene 
Verzeichnis geholt. Nun wird solange mit ParentDir() in das 
übergeordnete Verzeichnis gestiegen, bis das Hauptverzeichnis 
erreicht wurde. Dies geschieht mit Hilfe eines rekursiven Algo¬ 
rithmus. Es wird übrigens bei jedem Aufstieg ein neuer Fileln- 
foBlock allokiert. 

Wenn das Hauptverzeichnis erreicht wurde, wird der im FIB 
enthaltene Name in einen globalen String kopiert und das Zei¬ 
chen : angehängt. Da jetzt die einzelnen Rekursionstufen wieder 
verlassen werden, bildet sich der aufgerarbeitete File-Name, 
wobei zwischen zwei Verzeichnisnamen das /-Zeichen gesetzt 
wird. So entsteht aus dfO:include/exec z.B. SYSl:include/exec/. 

Bei der Ausgabe der File-Namen (GetDir()) wird dann, wenn 
auf ein auszugebendes Unterverzeichnis gestoßen wird, der 
Name dieses Unterverzeichnisses an den globalen Pfad-String 
angehängt und nach der Ausgabe wieder entfernt. 


2.5.6 Spielereien mit der Systemzeit 

Sicher haben auch Sie schon einmal die Fernsehwerbung einer 
deutschen Kaffeerösterei gesehen, in der ein Kaffeetrinkender 
Computerbenutzer auftaucht. Dieser schaltet gerade seinen 
Rechner ein, und auf dem Bildschirm erscheint die Meldung 
"GOOD MORNING". Wäre es nicht schön, wenn auch Ihr Amiga 
Sie so nett begrüßen würde? 

Dazu muß nur die Systemzeit ermittelt werden, in Abhängigkeit 
derer Ihr Computer Sie mit "Guten Morgen", "Guten Tag" oder 
"Guten Abend" begrüßt. Da wir nicht die Möglichkeit haben, 
den Amiga direkt nach dem Anschalten mit diesem Gruß zu 
beauftragen, muß dies beim Booten des Systems in der Startup- 
Sequenz geschehen. Aber natürlich wäre es recht einfallslos, den 
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Amiga jedesmal, wenn der Rechner neu gebootet werden muß - 
was bei Programmentwicklern ja recht häufig Vorkommen soll - 
einen Gruß von sich gibt. Der Amiga soll höchstens viermal am 
Tag grüßen. 

Dazu muß das Datum sowie die Uhrzeit des letzten Grußes ab¬ 
gespeichert werden. Erkennt das Programm, daß es an einem 
Tag schon mal "Guten Morgen" gesagt hat, läßt es den Gruß und 
wartet bis zur Mittagszeit. Schließlich ist Ihr Amiga kein über¬ 
triebener Heuchler: 


#include "exec/types.h" 

#inelüde "libraries/dos.h" 

# 1 nclüde "libraries/dosextens.h" 

VOID *Lock(); 

VOID *Open(); 

#define MORGEN OL /* Zeitabschnitte V 
#define TAG 1L 
#define ABEND 2L 
#define NACHT 3L 

struct DateStamp ActualDate, Systemzeit V 

OldDate; /* gespeichertes Datum */ 

#define READ_WRITEILEN (ULONG)sizeof(struct DateStamp) 

struct FileHandle ♦Handle = OL; 
struct FileLock *HandleLock = OL; 

char *FileName = *'SYS:Systemzeit''; 

VOID Gruss(OldDate, Date, Name) 
struct DateStamp 

♦OldDate,♦Date; 

char ♦Name; 

i 

LONG Hours; 

LONG OldHours; 

char ♦GrussString; 

LONG ZeitAbschnitt; 


Hours = Date->ds_Minute/60L; /♦ Stunden berechnen ♦/ 
OldHours = OldDate->ds_Minute/60L; 
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if ((Hours > 4L) SA (Hours <= 11L)) 

/* von 5 bis 11 Uhr */ 

i 

GrussString = “Guten Morgen“; 

ZeitAbschnitt := MORGEN; 

> 

if ((Hours > 11L) && (Hours <= 18L)) 

/* von 12 bis 18 Uhr */ 

i 

GrussString = “Guten Tag“; 

ZeitAbschnitt = TAG; 

> 

if ((Hours > 18L) && (Hours <= 22L)) 

/* von 19 bis 22 Uhr V 

< 

GrussString = “Guten Abend“; 

ZeitAbschnitt = ABEND; 

> 

if ((Hours > 22L) jj (Hours <= 4L)) 

/* von 23 bis 0 und 0 bis 4 Uhr */ 

i 

GrussString = “Gute Nacht“; 

ZeitAbschnitt = NACHT; 

> 

if (Date->ds_Days == OldDate->ds_Days) 

/* Wurde heute schon gegrüßt ? */ 
i 

if (((OldHours > 4L) && (OldHours <= 11L)) 

&& (ZeitAbschnitt != MORGEN)) 

/* Wurde heute schon GUTEN MORGEN gesagt ? */ 

printf(“%s Xs\n“, GrussString, Name); /♦-Nein V 
eise 

if (((OldHours > 11L) && (OldHours <= 18L)) 

&& (ZeitAbschnitt !~ TAG)) 

/♦ Wurde heute schon GUTEN TAG gesagt ? ♦/ 

printf(“%s Xs\n“, GrussString, Name); /♦ Nein V 
eise 

if (((OldHours > 18L) && (OldHours <= 22L)) 

&& (ZeitAbschnitt != ABEND)) 

/* Wurde heute schon GUTEN ABEND gesagt ? */ 

printf(“%s %s\n“, GrussString, Name); /♦ Nein V 
eise 

if (((OldHours > 22L} |j (OldHours <= 4L)) 

&& (ZeitAbschnitt 1= NACHT)) 

/♦ Wurde heute schon GUTE NACHT gesagt ? ♦/ 

printf(“Xs Xs\n“, GrussString, Name); /* Nein V 

> 

eise /* nein */ 
i 

printf (“%s %s\n“, GrussString, Name); 
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> 

> 

main(argc, argv) 

int arge; 

char *argv[]; 

C 

DateStampC&ActualDate); /* Systemzeit holen */ 

HandleLock = (struct FileLock *)Lock(FileName, (ULONG)ACCESS__READ); 
if (HandleLock == OL) 
i 

/* File "SYS:Systemzeit nicht vorhanden V 

Handle » (struct FileHandle *)Open(FileName, (ULONG)HOOE_NEWFILE); 
if (Handle == OL) 

printf("Kann <%s> nicht erzeugen !!!\n", FileName); 
exit (OL); 

/* Kein UnLockO nötig, da FileLock nicht erzeugt wurde */ 

> 

if (Write(Handle, ÄActualDate, READ_WRITEILEN) != READ^WRITEILEN) 

< /* Datum abspeichern V 
printf ("Schreibfehler !!!\n"); 

Close(Handle); 

exit(OL); 

> 

OldDate.ds^Days = OL; /* Immer grüssen V 
OldDate.ds_Minute = ActualDate.ds_Hinute; 

OldDate.ds Tick = OL; 

> 

eise 

< 

UnLock(HandleLock); /* Damit Open(),bzw. WriteO funktionieren 
kann */ 

Handle = (struct FileHandle *)Open(FileName, (ULONG)MOOE_OLDFILE); 
if (Handle « OL) 

< 

printf("Kann <%s> nicht öffnen !M\n", FileName); 
exit (OL); 

Kein UnLockO nötig, da schon ausgeführt V 

> 

if (Read(Handle, ÄOldDate, READ^WRITEILEN) != READ^WRITEILEN) 

{ /* Datum Lesen V 

printf("Lesefehler !!!\n"); 

Close(Handle); 

exit(OL); 

> 

Seek(Handle, OL, (ULONG)OFFSET.BEGINNING); 
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/* An den Anfang des Files zurückspulen */ 

if (WriteCHandle, ÄActualDate, READ_WRITE_LEN) != READ^WRITEILEN) 
i /* Datum Lesen */ 

printf("Schreibfehler !!!\n"); 

Close(Handle); 

exit(OL); 

> 

> 

Gruss(&OldDate, &ActualDate, argv[1]); 

Close(Handle); /* File muß hier immer geschlossen werden */ 


Programm Grüsse.c 


Dieses Programm ermittelt zunächst die Systemzeit. Dies geht 
mit dem Befehl DateStampO recht einfach. Dieser Befehl füllt 
eine DateStamp-Struktur (die auch im FilelnfoBlock enthalten 
ist) mit dem aktuellen Datum und der aktuellen Uhrzeit. Diesem 
Befehl wird als einziger Parameter die Adresse solch einer 
Struktur übergeben (DateStamp(&DateStamp-Struktur)). 

Daraufhin wird versucht, das File zu öffnen, das die Zeit des 
letzten Grußes enthält (SYS:Systemzeit). Ist dieses File nicht vor¬ 
handen, wird es erzeugt, und das aktuelle Datum wird hin¬ 
eingeschrieben. Außerdem wird in diesem Fall auf jeden Fall 
gegrüßt. Wenn es aber vorhanden ist, wird die darin enthaltene 
Systemzeit nach "OldDate" geladen, und diese Zeit durch die 
aktuelle Systemzeit ersetzt. Dazu wird der File-Positions-Zeiger 
mit Hilfe von Seek() zunächst an den Anfang des Files bewegt 
und dann das alte Datum vom aktuellen Datum überschrieben. 

Dann wird die Routine Gruss() aufgerufen, der das alte und das 
aktuelle Datum sowie der erste Kommandoparamter (argv[l]) 
übergeben wird. 

GrussO erkennt nun den Morgen daran, daß es noch nicht 11 
Uhr ist. Zwischen 11 Uhr und 18 Uhr wird "Guten Tag" gesagt, 
und ab 18 Uhr werden Sie mit "Guten Abend" begrüßt. Zwi¬ 
schen 22 und 5 Uhr erscheint "Gute Nacht". Um das ganze noch 
ein bißchen freundlicher zu gestalten können Sie dem Programm 
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auch noch Ihren Namen übergeben, so daß z.B. mit "Guten 
Abend Sabine" o.ä. gegrüßt wird (Komando-Parameter). 

Wenn Sie den Kommando-Parameter weglassen, macht das gar 
nichts, weil argv[l] dann ein leerer String ist, bei dessen Aus¬ 
gabe bekanntlich nichts passiert. 

Wenn Gruss() erkannt hat, welche Tageszeit gerade ist, wird 
festgestellt, ob das alte Datum mit dem aktuellen Datum über¬ 
einstimmt. Ist dies nicht der Fall wird auf jeden Fall gegrüßt. 
Wenn das alte und das aktuelle Datum aber übereinstimmen 
heißt das, daß heute schon mindestens einmal ein Gruß ausge¬ 
sprochen wurde. Um festzustellen, welcher, wird die alte Zeit 
zunächst auf die Tageszeit untersucht. Wenn zu dieser Tageszeit 
aber schon gegrüßt wurde - was daran erkenntlich ist, daß die 
Variable Zeitabschnitt den entsprechenden Wert (MORGEN, 
TAG, ABEND bzw NACHT) hat -, wird die Ausgabe des 
Grußes übersprungen und das Programm beendet. 

Theoretisch läßt sich dieses Programm beliebig erweitern. Man 
kann z.B. mit Hilfe des Narrator-Devices auch veranlassen, daß 
der Amiga regelrecht zu Ihnen spricht. Dazu wird die systemei¬ 
gene Stimme verwendet. Wenn Ihnen aber diese Stimme nicht 
gefällt, könnten Sie z.B. hingehen, und die Stimme Ihres Man¬ 
nes, Freundes, Ihrer Freundin oder Frau mit einem Digitizer 
samplen und dann abspielen lassen. 
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3. Intuition und C für Fortgeschrittene 


Dieses Kapitel beschäftigt sich mit der Programmierung des 
Amiga-Betriebssystems, und zwar speziell mit der Systempro¬ 
grammierung von Intuition. Sicherlich ist klar, daß mit C die 
nun weltbekannte Programmiersprache gemeint ist. Auch unter 
Systemprogrammierung kann man sich einiges vorstellen. Zum 
Beispiel: 

Wie sag’ ich meinem Amiga-Betriebssystem, daß ich 
einen bestimmten grafischen Aufbau haben möchte? 


oder ... 


Wie kann mir das System mitteilen, daß der User Eingaben 
vorgenommen hat (mit der Maus oder über die Tastatur)? 

Dies sind zwei Fragen, die unter das Thema Systemprogram¬ 
mierung fallen. Sicherlich gibt es noch weitere, und alle diese 
Fragen werden genau in diesem Kapitel beantwortet. 

"Intuition" ist die Bezeichnung für die Kommunikationsart, mit 
der man auf dem Amiga arbeitet. Unter Kommunikation verste¬ 
hen Sie bitte jeden Informationsaustausch, der direkt abläuft. Zu 
nennen sind da als Eingabemedium die Tastatur und die Maus - 
beide Einheiten sind ja im Lieferumfang des Rechners enthal¬ 
ten, doch bestimmt finden Sie noch mehr Medien. 

Die Ausgabe geschieht im wesentlichen über den Bildschirm. 
Dabei darf nicht vergessen werden, daß es auch noch Drucker 
und Disketten gibt, aber diese werden nicht über Intuition an¬ 
gesteuert und können deshalb nicht unter dieser Thematik er¬ 
läutert werden. 


Welche Mittel und Wege bietet Intuition? 

Beschäftigen wir uns zur Klärung dieser Frage zuerst mit den 
Ausgabewegen und -mittein: 
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Beim Booten der Workbench-Diskette sehen wir gleich zwei Me¬ 
dien, die uns Intuition zur Verfügung stellt. Zuerst und auch als 
Erstrangiges den Screen. Er bildet den Untergrund für jede 
Ausgabe! Als wichtigstes Beispiel ist dazu gleich der Workbench- 
Screen zu nennen, der ja wie eben beschrieben gleich beim 
Booten erscheint. Er begleitet den Benutzer auf Schritt und Tritt 
und wird auch für viele Programme als Ausgabeuntergrund ver¬ 
wendet. 

Für die Ausgabe selbst wird sehr selten ein Screen verwendet, 
dessen Handhabung nicht sehr einfach gestaltet ist. Um sich die 
Arbeit zu erleichtern, verwendet man Windows, die zweite Aus¬ 
gabeeinrichtung Intuitions. Die Windows werden vollständig von 
Intuition verwaltet und sind somit in den glücklicherweise weit 
gesteckten Grenzen nutzbar. Aber auch das sollte Ihnen bekannt 
sein, denn schließlich arbeitet man ja tagtäglich mit ihnen. 

Kommen wir nun zur Eingabe von Informationen. Das einfach¬ 
ste Eingabemedium sind die Gadgets! Sie befinden sich sowohl 
in Screens als auch in Windows und geben im einfachsten Fall 
nur einen Impuls weiter. Natürlich gibt es auch komplexere Ty¬ 
pen, mit denen man schon ganze Texte eingeben kann, doch 
dazu muß auch wieder die Tastatur benutzt werden, und wir 
wollen uns zuerst auf die Mauseingabe konzentrieren. 

Gadgets eignen sich zwar gut zur Informationseingabe, doch 
lassen sich komplexe Prozesse nicht so einfach mit ihnen auslö- 
sen. Für elementare Funktionen, die programmspezifisch sind, 
wurden die Menüs entwickelt. Auch sie werden über die Maus 
angesteuert, aber hier liegt der Schwerpunkt eindeutig auf der 
Textauswahl, während die Gadgets eher mit Grafiken ausge¬ 
drückt werden. Ausnahmen und Übergänge bestätigen die Regel! 
Hier haben Sie einen ersten Eindruck von den Fähigkeiten, die 
Ihnen Intuition bietet. Die Arbeit mit allen diesen Funktionen ist 
Ihnen bestimmt schon geläufig. Wir wollen uns hier vorrangig 
um folgende Frage kümmern: 


Wie programmiere ich das?' 
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Lassen Sie sich überraschen, welche Fähigkeiten in diesem Su¬ 
percomputer stecken! 


3.1 Windows, die Grundlage jeder Ein- und Ausgabe 

Wie schon in der Einleitung des Intuition-Kapitels gesagt, sind 
die Windows das wichtigste Ein- und Ausgabemedium! 

Wir haben uns zur Aufgabe gemacht, in diesem Buch die Be¬ 
schreibung zu liefern, wie Sie selbst eine Anwendung program¬ 
mieren können - von uns wurde ein Texteditor für C-Pro- 
gramme ausgesucht. Deshalb soll dieses Unterkapitel darüber 
Auskunft geben, wie Sie die Grundlagen für die Ein- und Aus¬ 
gabe programmieren und aus den vielen Möglichkeiten zusam¬ 
menstellen. Sie werden gleich erkennen, welche Vielfalt dem 
Programmierer von Intuition geboten wird. 

Nach der Aufzählung von Einstellungsmöglichkeiten werden wir 
uns an die Einrichtung eines von unserem Programm verwalteten 
Windows machen. Dabei lernen Sie kennen, wie man sich alle 
Befehle Intuitions zunutze macht, denn so einfach vorhanden 
sind sie nicht! 

Weiterhin erstellen wir zusammen ein allgemeines Window-Pro¬ 
gramm, das Sie immer wieder mit geringfügigen Änderungen 
benutzen können. Sie sollten dafür eine Diskette anlegen, denn 
diese Modulsystematik werden wir bis zum Ende des Buches 
weiterverwenden, um Ihnen viel Tipparbeit abzunehmen. 


3.1.1 Die Window-Parameter und wie man sie auswähit 

Für die Einstellungen eines Windows benötigen wir viele Para¬ 
meter, mit denen jede nur erdenkliche Größe festgesetzt werden 
kann. Um diese einzeln aufzuführen, rufen wir uns dafür die 
Eigenschaften, die uns von normalen Workbench-Windows be¬ 
kannt sind, in Erinnerung: 
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Außere Merkmale 

Jedes Window läßt sich in seiner Größe und Position verändern! 
Damit können wir folgende Werte einstellen: X-Position, Y-Po- 
sition, Breite, Höhe. 

Wenn sich ein Window in seiner Größe verändern läßt, so ist es 
in vielen Fällen wünschenswert, wenn man als Programmierer 
ein Maximum und Minimum angeben kann, um nicht am Ende 
vielleicht böse Überraschungen erleben zu müssen. Bei der Ar¬ 
beit mit der Workbench wird man es selten erleben, daß einem 
verboten wird, ein Inhaltsverzeichnis-Window weiter zu ver¬ 
größern oder zu verkleinern, doch vergessen wir nicht die Re- 
quester. Bei ihnen ist es nur erlaubt, sie zu verkleinern, ein Ver¬ 
größern ist vollkommen ausgeschlossen. Bei welchen Werten nun 
nicht mehr vergrößert oder verkleinert werden darf, kann man 
als Programmierer mit MaxBreite, MaxHöhe, MinBreite und 
Minhöhe einstellen. 

Außerdem, und das wissen vielleicht nicht alle, kann man die 
Farben bestimmen, natürlich in Abhängigkeit des Screens, mit 
denen der Window-Rand und die dort befindlichen Gadgets ge¬ 
zeichnet werden. Die zwei Farben werden als Zeichenstift und 
Blockstift bezeichnet. Ganz sicher gehört zu jedem Window auch 
eine Titelleiste mit ihrem Text. Auch dieser kann beliebig defi¬ 
niert werden. 

Für die, denen die wenigen System-Gadgets, so bezeichnet man 
die Gadgets, die von Intuition angeboten und teilweise auch 
verwaltet werden, nicht reichen, ist es vorgesehen, noch mehr 
Gadgets in ein Window einzubinden. So werden z.B. die 
Schiebebalken in den Verzeichnisfenstern verwaltet, denn sie 
sind nicht als System-Gadget definiert. Als Programmierer kön¬ 
nen wir jedes erdenkliche Gadget selbst konstruieren. 

Als letzte äußere Eigenschaft, die wir an jedem selbst erzeugten 
Window einstellen können, ist die Möglichkeit zu nennen, daß 
die System-Gadgets beliebig eingesetzt oder weggelassen werden 
können, je nachdem, was für eine Anwendung sinnvoll ist. 
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Weitere Einstellungen (innere Merkmale) 

Nachdem wir die offensichtlichen Einstellungen an einem Win¬ 
dow durchgesprochen haben, kommen jetzt die Einstellungen, 
bei denen nicht immer gleich grafische Veränderungen erkenn¬ 
bar sind. 

Eine Möglichkeit, die ziemlich selten genutzt wird, ist es, für 
den Haken, das sog. CheckMark, der Menüpunkte als abgehakt 
kennzeichnet, ein neues Aussehen zu definieren. Ich will Sie er¬ 
mutigen, dieses ruhig einmal auszuprobieren! 

Sie haben bestimmt schon von der wunderbaren Errungenschaft 
gehört, daß man einen eigenen Screen von Intuition verwalten 
lassen kann. Gehen wir von der Tatsache aus, daß wir einen ei¬ 
genen Screen besitzen und auf ihm unser neues Window ein¬ 
richten wollen. Dazu teilen wir dem Betriebssystem in einem 
Flag mit, daß es sich um ein Window handelt, welches nicht auf 
der Workbench erscheinen soll, sondern auf dem neuen Screen 
eingerichtet werden muß. Weiterhin benötigt Intuition aber noch 
die Information, auf welchem eigenen Screen, denn es ist 
durchaus denkbar, daß mehr als ein CustomScreen geöffnet 
wurde. Möchten wir also ein Window auf einem selbstdefinierten 
Screen öffnen, so kennzeichnen wir das durch ein Flag und 
übergeben der Struktur den Pointer auf den Screen. 


Programminterne Einstellungen (besondere Merkmale) 

Die Anwendungszwecke, mit denen Windows beauftragt werden, 
sind so vielfältig, daß man mit einem Standardtyp nicht jeder 
Anwendung gerecht werden kann. Aus diesem Grund wurden 
verschiedene Wege bereitgestellt, von denen sich der Program¬ 
mierer einen (oder mehrere) aussuchen kann. 


Erhaltung und Wiederherstellung des Window-Inhalts 

Der Inhalt eines Windows - das kann sowohl Text als auch Gra¬ 
fik sein - sollte möglichst unabhängig von anderen erhalten blei¬ 
ben, auch wenn diese zeitweise das eigene überlagern und somit 
Teile verdecken. Doch dazu würde Intuition, wenn es einfach 
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die verdeckten Bereiche Zwischenspeichern würde, man nennt 
das Puffern, sehr viel Speicherplatz benötigen. Aber in einigen 
Fällen ist das überhaupt nicht nötig. Weiß man nämlich, was sich 
im Window befindet und ist es ziemlich einfach wiederherzu¬ 
stellen, dann könnte man alles vom Programm aus vornehmen. 
Das bekannteste Beispiel ist die Workbench mit den Inhaltsver¬ 
zeichnissen. Dort werden die Icons einfach wieder neugezeich¬ 
net, wenn sie durch etwas anderes verdeckt wurden. Die Bilder 
werden also vom Programm Workbench restauriert und nicht 
über Intuition gepuffert. Dadurch erreicht man, daß sehr viel 
weniger Speicherplatz verbraucht wird, wenn sich viele Windows 
überlagern! 

Bei unserem eigenen Programm müssen wir deshalb zuvor über¬ 
legen, welchen Anwendungsbereich das Window abdeckt. Dabei 
sind drei grundlegend verschiedene Gebiete möglich: 

1. Programme, denen der Inhalt des Windows vollkommen 
bekannt ist und deren Daten sowieso in anderer Form ge¬ 
speichert sind. Ein Beispiel wäre da die Textverarbeitung, 
die den Text zusätzlich zur grafischen Information auf 
dem Bildschirm auch noch in ihrem Textpuffer speichert. 
Bei solchen Anwendungen empfiehlt es sich, die Wieder¬ 
herstellung selbst vorzunehmen, um anderen gleichzeitig 
laufenden Programmen möglichst wenig Speicherplatz 
wegzunehmen. 

2. Programme, die zeitlich nicht in der Lage sind, einen zer¬ 
störten Bereich wieder neu zu konstruieren. Hier würde 
man Intuition mit der Sicherung der überlagerten Bereiche 
beauftragen, um möglichst wenig Arbeit zu haben. Das 
Problem tritt häufig bei Grafiken auf, deren Neuzeichnen 
viel länger dauern würde als eine Zwischenspeicherung. 
Wichtig ist, daß der Speicherbedarf in einem richtigen 
Verhältnis zur Zeitersparnis steht, denn auch bei einem 
Computer mit 1 MByte RAM sollte der Speicherplatz 
sorgfältig verplant werden. 

3. Programme, die mehr Grafik-Display benötigen als über¬ 
haupt darstellbar ist. Für diese Kategorie ist eine vollstän¬ 
dig neue Methode entwickelt und bereitgestellt worden. 
Das Programm gibt seine Grafik in eine vollkommen ei- 



Intuition und C für Fortgeschrittene 


209 


genständige BitMap (so bezeichnet man den Gafikspei- 
cher), und Intuition holt sich daraus den gewünschten 
Ausschnitt für das Window. So kann bei jeder Wiederher¬ 
stellung auf den Grafikspeicher zurückgegriffen werden. 

Fassen wir noch einmal die drei Modi in einer Tabelle zusam¬ 
men, damit Sie einen kurzen prägnanten Überblick gewinnen 
können. Die Tabelle enthält weiterhin die Namen der Flags, die 
für den entsprechenden Modus gesetzt werden müssen. Es ist 
darauf zu achten, daß jeder Modus nur alleine lauffähig ist! 

Refresh-Art Flag Speicherverbrauch 

Einfach SIMPLE_REFRESH Keiner, denn Intuition kümmert sich 

nicht um das Window. 

Unterstützt SMARTERE FRESH Entsprechend der verdeckten Win¬ 

dow-Bereiche. 

Vollständig SUPER_BITMAP Die gesamte Grafik des Windows wird 

zwischengepuffert. 


Tabelle 3.1: Window-Refresh 


Spezielle Window-Typen 

Besondere Anwendungen erfordern es auch, besondere Window- 
Typen zur Verfügung gestellt zu bekommen. Dies wurde haupt¬ 
sächlich aus dem Grund in Erwägung gezogen, da mit einem 
Standard-Window-Typ sicherlich die eine oder andere Anwen¬ 
dung benachteiligt gewesen wäre. So ist es aber gelungen, sowohl 
unterstützende Anwender-Software leicht zu programmieren als 
auch ausgefallene Problemlösungen vorbildlich zu unterstützen. 


Randlose Windows 

Es ist keineswegs so, daß Ihr Window immer mit dem bekannten 
Rand, der aus Titelleiste, Gadgets und Begrenzungslinien be¬ 
steht, abgebildet werden muß. 

Wenn man von der primitivsten Möglichkeit ausgeht, so besteht 
ein Window nur aus einer Fläche, deren Inhalt getrennt von an¬ 
deren vielleicht vorhandenen Flächen behandelt wird. Der Rand 
(engl. Border), den Intuition darum zieht, dient nur der Ver- 
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ständlichkeit. Wären auf der Workbench alle Windows ohne die¬ 
sen Rand, dann würde sicherlich das totale Chaos herrschen. 

Es hat also einen tieferen Sinn, wenn man diese grafische Un¬ 
terteilung vornimmt. Aber sicherlich wird man auch eine An¬ 
wendung finden, bei der ein Rand unpassend wäre. Dafür 
kennzeichnen Sie das beim Einrichten eines neuen Windows mit 
einem Flag namens BORDERLESS. Doch achten Sie darauf, daß 
der Benutzer nicht durch ein solches Window verwirrt wird, 
denn man kann es überhaupt nicht erkennen, wenn es z.B. al¬ 
leine auf einem leeren Screen liegt. 


Benachteiligte Windows 

Der Titel lenkt hier etwas von dem eigentlichen Zweck ab, man 
sollte ihn deshalb nicht so wörtlich nehmen. Gemeint ist, daß 
solch ein Window nicht mehr die gesamten Eigenschaften nor¬ 
maler Windows hat. Es ist dazu "verdammt", immer das hinterste 
Window zu sein und somit von allen neu hinzukommenden 
überlagert zu werden. Es gibt keine Möglichkeit für den Benut¬ 
zer, dieses Window in den Vordergrund zu bringen. E>eshalb 
kann man auch nicht mehr alle System-Gadgets verwenden: Nur 
noch das Close-Gadget ist erlaubt. Das hat durchaus Vorteile: 

Sie können diesen Window-Typ als Untergrund für jede belie¬ 
bige Anwendung benutzen. Ob Sie nun einen Zeichentrickfilm 
ablaufen lassen, der durch das BACKDROP-Window einen 
Hintergrund erhält, oder ob Sie ein Zeichen-Tool programmie¬ 
ren, bei dem auf dem BACKDROP-Window gezeichnet wird 
und bei dem jedes weitere Window, das irgendwelche unterstüt¬ 
zenden Informationen oder Funktionen enthält, über diesem ge¬ 
öffnet wird. Alles dies sind Anwendungen, die durch die 
BACKDROP-Eigenschaft unterstützt werden, denn kein neues 
Window kann hinter das so bezeichnete gelegt werden. Das Pro¬ 
gramm braucht sich nicht darum zu kümmern, denn Intuition 
verwaltet alles. Wenn Sie diesen Typ bei der Initialisierung 
kennzeichnen wollen, so verwenden Sie das Flag mit dem Namen 
BACKDROP. 
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Eine interessante Kombination wäre z.B. ein BORDERLESS- 
BACKDROP-Window, das sich wunderbar für die oben ge¬ 
nannten Beispiele eignet. Aber Sie können nicht nur die ersten 
beiden Typen miteinander kombinieren. Auch die nächsten bei¬ 
den lassen sich hinzufügen: 


Ein extra Window-Rand 

Im vorhergehenden Text wurde beschrieben, wie man ein Win¬ 
dow erzeugt, das keinen Rand hat. Hier ist nun die genau entge¬ 
gengesetzte Einstellung beschrieben. Sie wissen ja, daß ein Win¬ 
dow eigentlich nur die rechteckige Fläche ist, die in den meisten 
Fällen noch grafisch durch den Rand von anderen abgehoben 
wird. Allerdings ergeben sich dadurch auch ein paar Probleme: 
Zeichnet man nämlich in ein solches Window, so kann es leicht 
passieren, daß beim Zeichnen die Titelleiste, die Gadgets oder 
der Rand übermalt werden, denn es ist nur eine Sperre einge¬ 
baut, die verhindert, daß man aus dem Window "rauszeichnet". 

Im Normalfall liegt es also beim Programm, sprich Programmie¬ 
rer, nicht in den Rand eines Windows zu zeichnen. Aber wer 
möchte schon dieses alles überprüfen und dann in ausführliche 
Abfragen umsetzen? Diese Voraussicht hatten auch die Ent¬ 
wickler von Intuition, und deshalb wurde der Modus 
GIMMEZEROZERO implementiert. Hier verändern sich einige 
bekannte Einstellungen. Das Window besteht nun aus zwei Fel¬ 
dern. Einmal aus dem Feld, in dem sich alle Gadgets, der 
Window-Titel und der Window-Rand befinden, und zusätzlich 
aus dem inneren Feld, in dem das Programm zeichnen kann, 
ohne darauf zu achten, ob es irgend etwas beschädigt. Der Name 
rührt daher, daß dieses innere Feld, es wird als "inner window" 
bezeichnet, in der linken oberen Ecke immer die Koordinaten 
0,0 hat, unabhängig von der Größe und dem Ausschnitt, der 
gezeigt wird. 

Für den zusätzlich betriebenen Aufwand wird auch mehr Spei¬ 
cher und Verarbeitungszeit in Anspruch genommen. Außerdem 
hat der Window-Teil, in den gezeichnet werden kann, ja nicht 
die bei der Definition angegebene Breite und Höhe. Dafür wur¬ 
den bei diesem Window-Typ extra zwei weitere Variablen ein- 



212 


Das große C-Buch zum Amiga 


gerichtet, die man abfragen kann, um sich über die Größe der 
wirklichen Zeichenfläche zu informieren. Es sind diese: GZZ- 
Height und GZZWidth. Dieser Bereich liegt zwischen den fol¬ 
genden Werten: BorderLeft, BorderTop, BorderRight, Border- 
Bottom. 

Da die Mauskoordinaten eines Windows immer auf die gesamte 
Fläche berechnet werden, kann dies hier zu einigen Problemen 
führen. Deshalb hält Intuition gleichzeitig noch Mauskoordinaten 
bereit, die sich auf das GIMMEZEROZERO-Window beziehen: 
GZZMouseX und GZZMouseY. 


Windows, die größer sind als sie selbst 

Intuition bietet dem Programmierer die Möglichkeit, eine viel 
größere Grafikfläche zu verwalten, als auf dem Screen abgebil¬ 
det werden kann. Gleichzeitig ist der sog. SUPER_BITMAP- 
Modus auch noch ein Window-Typ, bei dem auf eine ganz be¬ 
stimmte Art der Inhalt gerettet wird, doch dazu haben Sie ja 
schon oben unter dem Themengebiet Refresh etwas gelesen. Das 
Interessante an diesem Window ist, daß man eine fast beliebig 
große BitMap verwalten kann und nur einen Teil in seinem 
Window darstellt. Möchte man einen anderen Ausschnitt sehen, 
so wird einfach dieser abgebildet. Ganz wunderbar eignet sich 
diese Methode zum Scrollen (hin- und herrollen) einer Grafik. 

Wenn Sie diesen Window-Typ in ein Programm einbauen wollen, 
so setzen Sie einfach das SUPER_BITMAP-Flag. Eine Kombi¬ 
nation mit GIMMEZEROZERO oder BACKDROP ist durchaus 
möglich und kann teilweise auch sehr hilfreich sein. 


Die System-Gadgets im Window 

Gadgets sind Klickfelder, die mit der linken Maustaste aktiviert 
werden können. Intuition bietet vier Gadgets quasi als Startset 
an. Diese vier Gadgets unterstützen Funktionen, die normaler¬ 
weise nicht vom Programm bewältigt werden können. Ein wei¬ 
terer wichtiger Punkt sind ihre Eigenschaften! Alle System-Gad¬ 
gets sind in ihrer Position festgelegt. Ebenso ist die grafische 
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Gestaltung einheitlich und höchstens in der Farbe veränderbar. 
Man erkennt also immer die Bedeutung gleich wieder und 
braucht nicht lange zu raten. Sehen wir sie uns einzeln an: 

Das Close-Gadget 

Es dient zum Schließen des Windows. Der Vorgang ist Ihnen 
bestimmt von der Workbench vertraut: Sie wollen ein Verzeich¬ 
nisfenster nicht mehr haben und betätigen das Gadget in der 
linken oberen Ecke Ihres Windows. Und schon ist es vom Screen 
verschwunden! Sie erkennen das Gadget an dem Kasten, in dem 
sich ein dicker Punkt befindet. 

Das Drag-Gadget 

Sie erkennen es an den drei fetten Streifen in der Titelleiste des 
Windows. Mit ihm können Sie, wenn es im Window vorhanden 
ist, dessen Position ändern. Dazu brauchen Sie nur die Titelleiste 
anzuklicken, so lange den Button gedrückt zu halten und die 
Maus zu verschieben, bis die neue gewünschte Position erreicht 
ist. 

Die Depth-Arrangement-Gadgets 

Beide treten immer nur zusammen auf und dienen zum Über¬ 
oder Hinterlagern der Windows. Man findet sie in der rechten 
oberen Ecke. Wichtig ist immer die helle rechteckige Fläche. Sie 
stellt das eigene Window dar und somit auch die neue Position. 

Das Sizing-Gadget 

Wenn es vom Programm zugelassen ist, die Größe des Windows 
zu verändern, so finden Sie in der rechten unteren Ecke das Si¬ 
zing-Gadget. Es stellt ein kleines und ein großes Window durch 
zwei Rechtecke dar. Klicken Sie es einfach an, und halten Sie 
den Button gedrückt. Jetzt kann die Maus solange bewegt wer¬ 
den, bis die neue Größe eingestellt ist. Diese liegt aber nur in 
dem Bereich, der vorher durch die Minimal- und Maximalwerte 
bestimmt worden ist. 

Da durch das Sizing-Gadget der Rand des Windows, der Be¬ 
reich, in dem sich Intuition-Grafiken befinden, vergrößert wird, 
muß weiterhin noch angegeben werden, wo dieser Rand vom 
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wirklichen Ausgabefenster genommen werden soll. Als Möglich¬ 
keiten werden der rechte oder der untere Rand angeboten. Je 
nachdem, ob Sie mehr Zeilen oder mehr Spalten benötigen, ent¬ 
scheiden Sie diese Wahl. Es ist auch möglich, beide Bereiche für 
Intuition zu reservieren. 

Weiterhin muß beachtet werden, daß Intuition zwar eine Infor¬ 
mation durch das Close-Gadget erhält, diese jedoch nicht selbst 
verarbeitet. Wie darauf reagiert wird, hängt ganz von dem Pro¬ 
gramm ab, das das Window steuert. Intuition schließt das Fenster 
also nicht selbständig. Genauso wie das Programm eine Nach¬ 
richt erhält, wenn das Fenster geschlossen werden soll, bekommt 
es auch eine Nachricht, wenn die Größe des Fensters beeinflußt 
wurde, da dieses vom Programm sicherlich berücksichtigt wer¬ 
den muß. 


3.1.2 Wie verwaltet Intuition unser Window? 

Sie sind jetzt über die groben Einstellungen unterrichtet. Bevor 
wir uns ans Ausprobieren dieser Möglichkeiten machen können, 
müssen wir untersuchen, wie man überhaupt an die Intuition- 
Befehle herankommt und welchen Prinzipien diese unterliegen. 
Auch die interne Datenübermittlung soll uns interessieren. 


3.1.2.1 Der Zugang zur Intuition-Library 

Das ganze Betriebssystem des Amiga ist aus Befehlsgruppen zu¬ 
sammengesetzt. Diese nennt man Librarys (engl, für Bibliothek). 
Eine Library besteht aus verschiedenen Befehlen, denen alle 
Parameter übergeben werden und die auch Werte, z.B. Ergeb¬ 
nisse, zurückgeben können. 

Allerdings sind nicht alle Befehlsgruppen gleich beim Einschal¬ 
ten vorhanden. Selbst wenn sie schon geladen sind, so muß man 
noch ankündigen, daß man eine bestimmte Befehlsgruppe auch 
benutzen will, denn der Zugriff kann nur mit Hilfe eines Zei¬ 
gers geschehen. Dafür gibt es einen EXEC-Befehl (die Library, 
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die schon nach Einschalten über das Kickstart aktiv ist), der, 
wie alle EXEC-Befehle, jedem Programm zugänglich ist. 

library = OpenLibrarydibraryNatne, Version) 

DO A1 DO 

Sie Übergeben der Funktion den Namen der Library, in unserem 
Fall natürlich "intuition.library", und die Versionsnummer. Denn 
in neueren Versionen könnten ja Befehle sein, die eine alte Li¬ 
brary nicht enthält, und so können Sie sich davor schützen, eine 
Library zu laden, die gar nicht alle benötigten Befehle enthält. 

Wir wollen aber nur auf die Grundbefehle zurückgreifen, denn 
Windows gab es schon immer in Intuition. Die ersten Zeilen se¬ 
hen so aus: 

struct IntuitionBase *IntuitionBase; 
void ♦OpenLibraryO; 

if (!(IntuitionBase = (struct IntuitionBase *) 

OpenLibraryC'intuition.library“, NULL))) 

< 

printf (“Keine Intuition Library gefunden!\n“); 
exit (FALSE); 

> 


Programmteil 3.1: Open-Intuition 

Dokumentation 

In der ersten Strukturdefinition führen wir einen Zeiger ein, der 
auf die Befehlsliste von Intuition zeigt. Er wird vom Compiler 
benötigt, denn alle Befehle werden relativ zu diesem Zeiger an¬ 
gesprungen. Lassen Sie ihn ruhig einmal weg, die Fehlermeldung 
wird mir recht geben. 

Für die OpenLibrary()-Funktion haben wir in diesem Fall auch 
einen Zeiger von unbekanntem, d.h. gar keinem Typ definiert. 
Denn es kann durchaus sein, daß wir nicht nur die Intuition-Li¬ 
brary öffnen und dann gäbe es Probleme in der Typenum¬ 
wandlung! 

In der If-Überprüfung wird zuerst die Funktion selbst aufge¬ 
rufen und dann ihr Rückgabewert, der Zeiger auf die Intuition- 
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Befehle, auf Gültigkeit überprüft. Dieser Wert muß ungleich 
null sein, denn dann stellt er die Speicheradresse dar, an der die 
Library beginnt. Ansonsten bedeutet Null, daß ein Fehler auf¬ 
getreten ist. Im Befehlsteil von if wird dann ein Text in ein 
mögliches DOS-Window ausgegeben. Danach steigt das Pro¬ 
gramm über EXIT() aus. 

Jetzt fehlt nur noch die Anwort auf die Frage: "Wie beende ich 
den Zugriff auf eine Library?" Wenn wir wirklich den Zugriff 
bekommen haben, und nur dann, können wir ganz einfach die 
Library wieder schließen, und zwar mit dem EXEC-Befehl 
CloseLibraryO: 

CloseL 1 bra ry(LibraryZeiger) 

-414 A1 

In unserer Anwendung hieße das dann: 

CloseLibrary(IntuitionSase); 


3.1.2.2 Die NewWindow-Struktur 

Sie haben hiermit den prinzipiellen Aufruf der Library-Funk¬ 
tionen kennengelernt und auch, wie man sie wieder schließt. 
Dies läßt sich auf jede andere Library übertragen, was für Sie 
später bestimmt noch interessant sein wird. Beschäftigen wir uns 
zunächst wieder mit den Windows. Alle am Anfang dieses Ka¬ 
pitels besprochenen Eigenschaften eines Windows lassen sich 
natürlich beim öffnen einstellen und teilweise auch nachträglich 
verändern. Uns kümmert zuerst aber eine neue Frage: "Wie teile 
ich Intuition meine Startwerte mit?" Die Antwort lautet ganz 
einfach: "Mit Hilfe einer Struktur!" 

Wir benutzen für unser neues Window eine sog. NewWindow- 
Struktur, die alle Werte enthält, die Intuition benötigt, um ein 
neues Window einzurichten. Die Struktur hat folgendes Aus¬ 
sehen: 
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struct NewWindou 
{ 

0x00 00 SHORT LeftEdge; 

0x02 02 SHORT TopEdge; 

0x04 04 SHORT Uidth; 

0x06 06 SHORT Height; 

0x08 08 UBYTE DetailPen; 

0x09 09 UBYTE BlockPen; 

OxOa 10 ULONG IDCHPFlags; 

OxOe 14 ULONG Flags; 

0x12 18 struct Gadget *FirstGadget; 

0x16 22 struct Image *CheckMark; 

Oxia 26 UBYTE »Title; 

0x1e 30 struct Screen »Screen; 

0x22 34 struct BitMap »BitMap; 

0x26 38 SHORT MinUidth; 

0x28 40 SHORT MinHeight; 

0x2a 42 USHORT MaxUidth; 

■0x2c 44 USHORT MaxHeight; 

0x2e 46 USHORT Type; 

0x30 48 

> 

Wie Sie ja wissen, besteht eine Struktur aus einer Ansammlung 
vieler zum Teil verschiedener Variablen. Sie werden sich viel¬ 
leicht wundern, warum vor den Variablentypen-Deklarationen 
mit ihren Namen auch noch Zahlen stehen, die im normalen C- 
Programm nicht zu finden sind. Diese Zahlen zeigen Ihnen den 
Offset an, unter dem die Variablen später im Speicher aufge¬ 
funden werden können. Für die, die manchmal mit dem 
Debugger arbeiten oder sich etwas in Assembler auskennen, 
kann es eine große Hilfe sein. Wie Sie damit richtig umgehen, 
können Sie im zweiten Kapitel nachlesen. 

Die einzige wichtige Schlußfolgerung, die Sie aus dem obigen 
Absatz ziehen müssen, ist, daß Sie nie, nie, nie die Zahlen mit 
abtippen dürfen! 

Als letztes sei noch angemerkt, daß die erste Spalte hexadezimal 
und die zweite den Funktions-Offset dezimal ausdrückt. Die 
letzte Zahl beziffert die Gesamtlänge der Struktur. Das kann für 
die Speicherplanung nicht unwesentlich sein! 

Bis hierhin haben wir geklärt, auf welcher Grundlage unsere 
Kommunikation mit Intuition abläuft. Man kann dies als allge¬ 
meingültig für alle Librarys festhalten. Jeder Kontakt zu den 
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Unterprogrammen läuft dann über vordefinierte Funktionen ab, 
denen wir Werte übergeben, wie z.B. der OpenLibraryO- oder 
CloseLibraryO-Funktion. Intuition wird sogar, wie auch die 
meisten anderen Librarys, zu seinen Verwaltungszwecken eigene 
Strukturen anlegen, in denen wir nachschauen können, um uns 
Daten, d.h. Informationen zu verschaffen. Kommen wir jetzt zur 
aktiven Arbeit mit Intuition: 


Einrichtung einer NewWindow-Struktur 

Die Überschrift gibt zwar den Hauptgedanken wieder, doch 
rankt sich noch viel mehr drumherum. Wir werden die Grund¬ 
bausteine der weiteren Entwicklungsarbeit legen und dazu gleich 
zwei Funktionen entwerfen, die dann in das erste Window-Pro¬ 
gramm eingebaut werden. Aber jetzt zu den beiden Funktionen, 
die, wie Sie sofort erkennen werden, einen guten Zweck erfüllen 
und helfen, später vielleicht auftretende Probleme mit Leichtig¬ 
keit zu lösen. 

Die erste Funktion soll alles das beinhalten, was am Anfang des 
Programms geöffnet, intitialisiert, besorgt oder organisiert wer¬ 
den muß. Dazu zählt z.B.: Speicher besorgen, Librarys öffnen, 
Felder löschen, Zugriffe sichern ... 

Die zweite Funktion soll entsprechend alles das beinhalten, was 
am Ende wieder geschlossen werden muß. Denn würden wir z.B. 
eine Library nicht mehr schließen, so würde der zur Verwaltung 
benötigte Speicherplatz dem System nie wieder zurückgegeben 
werden. Daß so etwas nicht passieren darf, liegt auf der Hand! 

Die Lösung dieser Aufgaben sieht zwar einfach aus, doch haben 
wir bis jetzt ein klitzekleines Problem außer acht gelassen: Es 
könnte ja beim Öffnen der Fall sein, daß aus irgendeinem 
Grund etwas fehlschlägt (ein Speicherbereich ließ sich nicht be¬ 
reitstellen... ). In dieser Situation sollte ein Fehlertext ausgegeben 
werden, und das Programm müßte abgebrochen werden. Wir 
dürfen aber nicht vergessen, vorher alles schon Geöffnete wieder 
zu schließen. Aber gerade hier liegt die Fehlerstelle! 
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Wenn man nämlich einfach zur Schließroutine springt, so wür¬ 
den vielleicht auch Sachen geschlossen werden, die gar nicht ge¬ 
öffnet wurden. Aber dann "stürzt" die Betriebssystemroutine 
unter Garantie ab, denn keine ist gegen diese Möglichkeit gesi¬ 
chert. Wir schreiben deshalb eine Schließfunktion, die in Abhän¬ 
gigkeit von Pointern, die ja bei jedem öffnen als Resultat ge¬ 
wonnen werden, alles Geöffnete wieder schließt, alles andere 
aber aus dem Spiel läßt. Sehen wir uns die Funktionen an: 



* Wgb 16.10.1987 nur Intuition * 

* * 
************************4r**************^ 

i 

void ^OpenLibraryO; 


if (!(IntuitionBase = (struct IntuitionBase *) 
OpenLibraryC'intuition.library”, NULL))) 
i 

printfC'Keine Intuition Library gefunden!\n"); 

Close AUO; 

exit(FALSE); 

> 

> 


Funktion 3.1: Open jill 



***************************************y 

{. 

if (IntuitionBase) CloseLibrary(IntuitionBase); 

> 


Funktion 3.2: Close All 
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Dokumentation 

Die Arbeit der ersten Funktion ist uns schon bekannt. Der Inhalt 
der zweiten ist fast lächerlich, doch liegt der Hauptteil der 
Überlegung auf der If-Abfrage, denn ohne sie würde das Pro¬ 
gramm "abstürzen", sobald durch irgendeinen Umstand die In¬ 
tuition-Library nicht erreicht und somit nicht geöffnet werden 
konnte. 

Beide Funktionen sehen im ersten Moment zwar einfach und 
kurz aus, doch haben sie den Sinn und die Aufgabe, ständig er¬ 
gänzt zu werden! Tippen Sie sie deshalb sorgfältig ab, und 
speichern Sie beide auf Ihrer Programmdiskette in einem Unter¬ 
verzeichnis für Funktionsblöcke. Wenn eine von beiden benötigt 
wird, finden Sie nicht mehr das gesamte Listing vor, sondern 
nur noch einen Hinweis auf den schon bekannten Teil und die 
für das Programm benötigten Ergänzungen. 

Nach der Erarbeitung unseres elementaren Grundinventars kön¬ 
nen wir endlich mit dem ersten Programm beginnen, das die 
Aufgabe hat, ein einfaches Window zu öffnen und nach einiger 
Zeit wieder zu schließen. Wie schon im vorhergehenden Unter¬ 
kapitel angesprochen wurde, benötigt Intuition für die Einrich¬ 
tung eines Windows einige Informationen, die wir über eine 
Struktur übermitteln. Das Aussehen dieser NewWindow-Struktur 
ist bekannt. Legen wir jetzt die Eigenschaften des ersten Win¬ 
dows fest: 

Im Prinzip ist die Position und Größe für unseren Test egal, 
doch bitte wählen Sie Breite und Höhe nicht zu klein, denn für 
die Gadgets und den Window-Rand muß ja noch Platz sein. Ich 
habe mich für die Position 160, 50 mit der Ausdehnung 320, 200 
entschieden. Schreiben wir die Werte in die Struktur, die übri¬ 
gens FirstNewWindow heißt: 

FirstNewWindow.LeftEdge = 160; 

FirstNewWindow.TopEdge = 50; 

FirstNewWitxlow.Uidth = 320; 

FirstNewWindow.Height = 200; 
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Da ich das Sizing-Gadget nicht weglassen will, entscheide ich 
mich für die Screen-Ausdehnung als Maximum. Das Minimum 
sollte nicht zu klein gewählt werden! 


FirstNewWindow.MinUidth = 100; 
FirstNewUindow.MinHeight = 50; 
FirstNewUindow.MaxUidth = 640; 
FirstNevMindow.MaxHeight = 256; 


Bevor wir uns mit den etwas komplexeren Einstellungen in der 
NewWindow-Struktur beschäftigen, sollen noch die Parameter 
abgehandelt werden, mit denen wir uns erst später auseinander¬ 
setzen können: 

Weil wir noch keinen Screen selbst verwalten können, bleibt 
nichts anderes übrig, als die Workbench zu benutzen. Der Typ 
des Windows steht dadurch fest, und ein Zeiger muß nicht ge¬ 
sucht werden. 

FirstNeuUindow.Type = UBENCHSCREEN; 

FirstNewWindow.Screen = NULL; 

Eigene Gadget-Definitionen folgen in einem Extrakapitel, und 
auch die Menüs sollen nicht sofort angesprochen werden: 

FirstNewWindow.FirstGadget = NULL; 

FlrstNewWindow.CheckMark = NULL; 

Gehen wir jetzt über zu den grafischen Details. Da haben wir 
zuerst den Window-Titel! Entweder man gibt einen Pointer an, 
der auf eine mit Null beendete Zeichenkette zeigt - die im wei¬ 
teren Text als String bezeichnet wird, oder wir übergeben einen 
Null-Pointer, d.h. wir wollen keinen Text in der Titelzeile. Ist 
dann gleichzeitig auch kein System-Gadget zugelassen, so wird 
überhaupt keine Titelleiste dargestellt! 

Bei der Arbeit mit dem Aztec-Compiler sollte vor dem String 
noch eine Cast-Anweisung stehen. Nur so vermeidet man die 
altbekannten und lästigen Warnings. 

FirstNewWindow.Title = (UBYTE *)"Systefliprograninierung Test"; 
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Eine interessante Einstellung, deren Möglichkeiten aber nur sel¬ 
ten genutzt werden, sind die beiden Farbstifte. Entsprechend des 
Screens können sie einen Wert zwischen 0 und 31 annehmen, der 
natürlich von der Anzahl der Bitplanes abhängig ist. Einen be¬ 
sonderen Wert stellt -1 (OxFF) dar! Bei dieser Einstellung wird 
nicht, wie man vielleicht denken könnte, zufällig eine Farbe 
ausgesucht, sondern die Farbauswahl richtet sich jetzt nach den 
Dafault-Werten des Screens. Mit der Implementierung dieser 
Methode hat man es erreicht, alle Windows eines Screens im 
gleichen Farbstil auszugeben, und gleichzeitig kann so global die 
Farbe geändert werden. In der Beispieleinstellung sind zwar auch 
die Farbwerte der Workbench gewählt, trotzdem wird nicht auf 
die Default-Werte zurückgegriffen. Dies macht das neue Window 
unabhängig von den Einstellungen des übergeordneten Screens, 
auch wenn dieser im Moment die gleichen Werte enthält. 

FlrstNewWindow.DetailPen =0; 

FirstNewUindow.BlockPen =1; 

Von allen Parametern, die wir bei der Initialisierung beeinflus¬ 
sen können, fehlen nur noch zwei. Es sind zwei Flag-Parameter, 
deren Möglichkeitenspektrum so komplex ist, daß wir uns etwas 
genauer damit auseinandersetzen sollten. Richten wir dazu un¬ 
seren Blick zuerst auf die einfachen Flags. Sie lassen sich grob 
in fünf Gruppen unterteilen; 


1. Die Gadget-Flags 

Je nachdem, welches System-Gadget im Window vorhanden sein 
soll, müssen die Flags gesetzt werden. Folgende stehen zur Aus¬ 
wahl: 

WINDOWDRAG 

Das Window läßt sich mit Hilfe der Titelleiste im Screen posi¬ 
tionieren. 

WINDOWDEPTH 

Das Window läßt sich durch die beiden Gadgets hinter oder vor 
andere Windows bringen. 
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WINDOWCLOSE 

Versieht das Window mit dem Schließ-Gadget, das vom Pro¬ 
gramm aus abgefragt werden kann. 

WINDOWSIZING 

Versieht das Window mit dem Sizing-Gadget, damit die Größe 
vom Benutzer geändert werden kann. 


2. Die Sizing-Gadget-Position 

Aufgrund des letzten Gadgets mußten noch zwei weitere Flags 
integriert werden, da alle System-Gadgets in den sog. Window- 
Borders untergebracht werden. Es erscheint klar, daß für die er¬ 
sten drei der obere Window-Rand genommen wird. Doch beim 
Sizing-Gadget stehen zwei Möglichkeiten zur Diskussion. 

SIZEBRIGHT (SIZ(E)ing-Gadget im RIGHT Border) 

Der rechte Window-Rand wird für das Sizing-Gadget verwendet. 

SIZEBBOTTOM (SIZ(E)ing-Gadget im BOTTOM Border) 

Der untere Window-Rand wird für das Sizing-Gadget verwendet. 


3. Die Refresh-Flags 

Der Inhalt eines Windows kann leicht durch Überlagerung an¬ 
derer zerstört werden. Natürlich muß man dem nicht tatenlos 
Zusehen! Intuition bietet verschiedene Möglichkeiten, der Situa¬ 
tion zu begegnen: 

SIMPLE_REFRESH 

Die einfachste Art des Refreshes. Dieser Refresh-Status bedeu¬ 
tet, daß Intuition überhaupt keine Anstrengungen unternimmt, 
das Window wiederherzustellen. Jede Restauration muß vom 
Programm bzw. dem Programmierer organisiert werden. 

SMART_REFRESH 

Hier hat Intuition schon einiges zu tun! Jeder verdeckte Bereich 
des Windows wird von Intuition zwischengespeichert, d.h. ge- 
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puffert, und nach optischer Freigabe wieder dargestellt. Pro¬ 
bleme bringt diese Methode nur, wenn das Window durch das 
Sizing-Gadget beeinflußt wurde! Durch Verkleinerungen ver¬ 
schluckte Teile des Windows werden nicht zwischengespeichert 
und auch nicht wiederhergestellt. 

SUPER_BITMAP 

Die speicheraufwendigste Art der Window-Sicherung. In einigen 
Fällen kann es Vorkommen, daß eine wesentlich größere Grafik 
gespeichert werden muß, als mit dem Window dargestellt wird. 
Dafür gibt es diesen Window-Typ. Er dient also einmal als Re¬ 
fresh-Modus, denn aus der eigenen BitMap der Window-Grafik 
kann ja immer wieder jede beliebige Information für den Re¬ 
fresh geholt werden, andererseits wird es gleichzeitig unterstützt, 
Grafiken mit übergroßen Dimensionen zu verwalten. 

NOCAREREFRESH 

Ruhe auf der Datenleitung! Die Window-Typen SMART_ 
REFRESH und SIMPLE_REFRESH erfordern teilweise oder 
auch größtenteils die Mitarbeit des Programms, denn bei 
SMART_REFRESH weiß Intuition beim Sizing-Vorgang nicht 
mehr weiter, und bei SIMPLE_REFRESH muß bei jeder Über¬ 
lagerung neu gezeichnet werden, wenn einem am Inhalt etwas 
liegt. Das Programm erhält deshalb über eine Datenleitung die 
Nachricht, daß etwas getan werden muß. Die Datenleitung und 
ihre Handhabung wird später erklärt. Will man aber überhaupt 
nichts tun, so blockieren ständige Nachrichten sicherlich diese 
Leitung. Mit diesem Flag kann man das unterbinden und sagen, 
daß keine Information erwünscht ist. 


4. Die Flags für die Window-Typen 

Im Abschnitt über die verschiedenen Window-Typen wurden 
schon die Haupteigenschaften und Anwendungsgebiete aufge¬ 
zählt. Hier nur noch einmal die Flag-Namen mit kurzem Kom¬ 
mentar: 
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BACKDROP 

Das Window wird immer hinter allen anderen Windows liegen. 
Hier ist es nur sinnvoll, höchstens ein solches Window pro 
Screen einzurichten. 

SUPERBITMÄP 

Obwohl SUPER_BITMAP auch ein Refresh-Typ ist, gilt es 
gleichzeitig auch als Window-Typ. Es gibt trotzdem nur ein 
Flag. 

BORDERLESS 

Intuition unterläßt es, den Window-Rand zu zeichnen (s.u.). 
GIMMEZEROZERO 

Intuition verwaltet den Rand des Windows, da wo alle System- 
Gadgets untergebracht werden und auch eigene Gadgets liegen 
können, getrennt vom Inhalt. Das erleichtert die grafische Hand¬ 
habung. 


5. Die Maus-Flags und der Rest 

Wir kommen jetzt zu den drei letzten Flags. Zwei davon bezie¬ 
hen sich auf die Maus. Mit der anderen wird einfach nur einge¬ 
stellt, ob das Window beim öffnen gleich aktiv sein soll. 

ACT IVATE 

Bei gesetztem Flag wird, wie gerade erwähnt, das Window sofort 
beim öffnen aktiv. Dies ist sicherlich oft wichtig, denn die Ein¬ 
gabe wird immer in das aktive Window geleitet. Das kann Kon¬ 
sequenzen haben, wenn der Benutzer gerade etwas eingibt, wenn 
ein neues Window mit diesem Flag aufgemacht wurde. Benutzen 
Sie solche Windows mit Vorsicht! 

REPORTMOUSE 

Mit dem Setzen dieses Flags erhält man ständig eine Nachricht 
über die aktuelle Mausposition. 
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RMBTRAP (Right Mouse Button TRAP) 

Alle Maus-Signale des rechten Maus-Buttons werden in Signale 
des linken Buttons umgewandelt. Das ist anwendbar, wenn keine 
Menüs vorhanden sind o.ä. 

Alle aufgeführten Flags werden als gesetzte oder gelöschte Bits 
des Flag-Eintrags in der NewWindow-Struktur dargestellt. In der 
C-Programmierung können Sie natürlich den bekannten und 
wesentlich leichter zu merkenden Namen verwenden. Aber für 
die Assembler-Freunde und alle, die mehr Informationen wün¬ 
schen, hier eine Tabelle aller Flags und der dazugehörigen Werte: 


Flag-Name 

WINDOUSIZING 

UINDOWDRAG 

WINDOWDEPTH 

UINDOUCLOSE 

SIZEBRIGHT 

SIZEBOTTOM 

NOCAREREFRESH 

SIMPLE_REFRESH 

SMART^REFRESH 

SUPER_BITMAP 

BACKDROP 

GIMMEZEROZERO 

BORDERLESS 

ACTIVATE 

REPORTMOUSE 

RMBTRAP 


Hex-Wert 

0x000000011 

0x000000021 

0x000000041 

OxOOOOOOOSL 

0x0000001OL 
OxOOOOOOZOL 

OxOOOZOOOOL 

0x00000040L 

OxOOOOOOOOL 

OxOOOOOOSOL 

0x000001OOL 
0x00000400L 
OxOOOOOSOOL 

0x00001OOOL 
OxOOOOOZOOL 
0x00010000L 


Gruppe 

System-Gadgets 


Gadget-Position 


Refresh-Typen 


Window-Typen 


Maus-Flags 


Tabelle 3.2: Window-Flags 


Als Ergebnis der obigen Analyse aller normalen Window-Flags 
ergibt sich folgende Definition in der NewWindow-Struktur: 

FirstNewWindow.Flags = WINDOWDEPTH j WINDOWSlZING | 

WINDOWDRAG | WINDOWCLOSE j SMART_REFRESH; 
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Nachdem wir die einfachen Flags betrachtet haben, kommen wir 
nicht um die IDCMP-Flags herum! Dazu sollten Sie zuerst wis¬ 
sen, was unter "IDCMP" zu verstehen ist. Der Begriff stellt eine 
Abkürzung aus dem Englischen dar: "Intuition Direct Commu- 
nication Message Ports", was zu deutsch etwa heißt "Intuitions 
direkter Kommunikations-Nachrichten-Kanal". Diese wörtliche 
Übersetzung bringt uns aber nur weiter, wenn wir verstehen, zu 
welcher Kommunikation dieser direkte Nachrichtenkanal genutzt 
wird. 

Der IDCMP-Kanal ist eine sehr komplexe Datenleitung, die In¬ 
formationen zu allen auf Intuition bezogenen Bereichen liefert. 
Hier soll eine Aufzählung ausreichen, denn das Thema ist so 
umfangreich, daß ihm ein ganzes Kapitel gewidmet wurde. Al¬ 
lerdings werde ich schon hier einige Informationen mit ein¬ 
fließen lassen, denn ganz ohne diesen IDCMP-Kanal kommen 
Sie bei Intuition nicht aus, ohne irgendwelche großen Ein¬ 
schränkungen hinnehmen zu müssen. 

Zu folgenden Themengebieten können Sie Informationen erlan¬ 
gen: Windows, Gadgets, Menüs, Maus, Tastatur, Disk, Prefe- 
rences, Uhr. 

Da wir aber noch überhaupt nichts darüber wissen, behelfen wir 
uns auf eine trickreiche Art. Anstatt das Window, das ja von 
unserem Programm geöffnet werden soll, durch ein Close-Gad- 
get zu schließen, wird es nach einer bestimmten Zeit wieder 
entfernt. Somit haben wir uns wenigstens zu Anfang von dem 
Vorgriff befreit: 

FirstNewUindow.IDCHPFlags = NULL; 

Damit wäre die Strukturdefinition von FirstNewWindow abge¬ 
schlossen. Sehen Sie sich einmal das Programm an. Es ist aus den 
beiden Funktionen Open_All() und Close_All(), der Struktur 
und einem Hauptprogramm zusammengesetzt : 
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^*4r**************4r********************** 

* * 

* Programm: Window lokale Definition * 

* ============:s==:===s:s==:========ss=== * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ * 

* Wgb 16.10.1987 erstes Test- * 

* Window * 

* * 
***************************4r****4r******^ 


#include <exec/types.h> 

#include <intuition/intuition.h> 


struct IntuitionBase *IntuitionBase; 
struct Window *FirstWindow; 


struct NewWindow FirstNewWindow; 

void *OpenLibrary<); 

struct Window *OpenWindowO; 

mainO 

< 


FirstNewWindow.LeftEdge = 160; 

FirstNewWindow.TopEdge = 50; 

FirstNewWindow.Width = 320; 

FirstNewWindow.Height = 200; 

FirstNewWindow.DetailPen = 0; 

FirstNewWindow.BlockPen = 1; 

FirstNewWindow.IDCMPFlags = NULL; 

FirstNewWindow.Flags = WINDOUDEPTH j UINDOUSIZING | 

UINDOUDRAG | WINDOUCLOSE | 
SMART_REFRESH; 


FirstNewWindow.FirstGadget= NULL; 


FirstNewWindow.CheckMark 
FirstNewWindow.Title = 
FirstNewWindow.Screen 
FirstNewWindow.BitMap 
FirstNewWindow.MinWidth 
FirstNewWindow.MinHeight 
FirstNewWindow.MaxWidth 
FirstNewWindow.MaxHeight 
FirstNewWindow.Type 


= NULL; 

(UBYTE *)'*Systefflprogrammierung Test“ 
= NULL; 

= NULL; 

= 100; 

= 50; 

= 640; 

= 256; 

= WBENCHSCREEN; 


Open^AllO; 

Delay(180L); 
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Close AU(); 

> 


^*****4r**********************Sr********** 
* * 

* Funktion: Library und Window öffnen * 

* ss:=s==:s====s==;=s:=s=;=:=====s==z==s==3: * 

* * 

* Autor: Datum: Kommentar: * 

★ _ _ _ ♦ 

* Wgb 16.10.1987 * 

* * 


***********illr****«r**********************y 

i 


if (!(IntuitionBase = (struct IntuitionBase *) 
OpenLibraryC'intuition.library“, OL))) 
i 

printfC'Keine Intuition Library gefunden!\n") 

Close__AU<); 

exit(FALSE); 

> 


if <KFirstWindow = (struct Window ♦) 

OpenWindow(&FirstNewWindow))) 
i 

printf("Window will nicht aufgehen!\n"); 

Close AIK); 

exit(FALSE); 

> 

> 


y*************************************** 


* * 

* Funktion: Alles Geöffnete schließen ♦ 

★ =========:======:=:=:=====:=:==========:==: * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ ♦ 

* Wgb 16.10.1987 nur Intuition * 

* und Window * 

* * 
4r4r*4r***********************************y 

c 

if (Firstwindow) CloseWindow(Firstwindow); 


if (IntuitionBase) CloseLibrary(IntuitionBase) 
> 


Programm 3.1: '"Erstes Window' 
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Dokumentation 

Das Listing bringt trotz der bekannten Teile doch noch einige 
wichtige Neuigkeiten. Zuerst einmal ist die Open_All()-Funk- 
tion um das Öffnen des Windows ergänzt worden, dementspre¬ 
chend natürlich auch die Close_All()-Funktion um das Schließen 
des Windows. Weitere Erläuterungen zu anderen Intuition-Funk¬ 
tionen bezüglich der Windows kommen im Anschluß an diese 
Dokumentation. 

Wie geschieht nun das öffnen eines Intuition-Windows, wenn 
man zuvor seine NewWindow-Struktur definiert hat? Zuerst 
einmal ist es sehr wichtig, daß die Struktur vor der main()- 
Funktion definiert wurde, da sonst die Struktur-Werte den an¬ 
deren Funktionen nicht zugänglich sind. Der OpenWindow- 
Funktion wird dann einfach die Adresse unserer Definitions¬ 
struktur (NewWindow) übergeben. Als Wert erhalten wir einen 
Zeiger auf die Window-Struktur zurück, die aufgrund unserer 
Daten angelegt wurde. Sie enthält noch einige weitere Verwal¬ 
tungsinformationen. Genauso wie auch bei OpenLibrary über¬ 
prüft werden mußte, ob kein Fehler aufgetreten ist, darf auch 
bei OpenWindowO nicht immer damit gerechnet werden, daß 
alles glücklich abgelaufen ist. Es gibt so viele Gründe, die 
OpenWindowO verhindern können, z.B. zu wenig Speicherplatz. 
Die Schutzabfrage ist der schon bekannten angeglichen. Die 
NewWindow-Struktur kann jetzt wieder gelöscht werden. Sie 
wurde nur zum Einrichten benötigt! 

UindowPointer = OpenWindowtNewWindowStruktur) 

DO -204 AO 

Aber auch das Schließen des Windows wurde in der 
Close_All()-Funktion ergänzt. Der Aufbau gleicht auch hier 
wieder dem schon Bekannten. Wichtig ist, daß erst das Window 
geschlossen wird und dann die Intuition-Library. Würde man 
umgekehrt verfahren, so wäre dem Betriebssystem die Funktion 
CloseWindowO gar nicht mehr bekannt, und ein Absturz wäre 
sicher! 

CtoseUindow(UindowPointer) 

-72 AO 
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Im Hauptprogramm, in der Funktion main(), wurde zwischen 
Open_All() und Close_All() eine Verzögerung durch DelayO 
eingebaut. Diese Betriebssystemfunktion legt den Task unseres 
Programms so lange in den Wait-Status, bis die angegebene Zeit 
verstrichen ist (die Zeit wird in "Ticks" angegeben, 50 Ticks 
entsprechen einer Sekunde), da wir, wie schon angesprochen, 
noch nicht die Möglichkeit haben, das Close-Gadget abzufragen, 
um das Window wieder schließen zu lassen. Anstatt der DelayO- 
Funktion hätten wir natürlich auch eine For-Schleife zur Ver¬ 
zögerung heranziehen können. Doch dann hätten wir das Multi¬ 
tasking verlangsamt, obwohl wir nur warten wollten. 

Betrachten wir zum Abschluß noch den Anfang des Programms 
und seine Kommentarblöcke. Vor der main()-Funktion werden 
zwei Strukturen definiert, die für unser Window unentbehrlich 
sind. Zuerst die NewWindow-Struktur mit dem Namen First- 
NewWindow. Damit reservieren wir Speicherplatz für die Infor¬ 
mationen, die Intuition zur Einrichtung unseres Windows benö¬ 
tigt. Die zweite Struktur wird mit einem Pointer auf sie erreicht. 
Er zeigt auf eine Window-Struktur. Diese ist von der NewWin¬ 
dow-Struktur dadurch zu unterscheiden, daß sie viel mehr In¬ 
formationen enthält und außerdem mit weiteren Windows ver¬ 
bunden ist, man bezeichnet dies als Linken. Der Aufbau im Sy¬ 
stem, das von Intuition eingerichtet und verwaltet wird, sieht 
wie folgt aus: 

Den Grundstock bildet ein Screen, meistens der Workbench- 
Screen. In dieser Screen-Struktur, sie wird noch ausführlich im 
nächsten Kapitel erläutert, wird ein Zeiger aufbewahrt, der auf 
das erste Window des Screens zeigt. Die Window-Struktur selbst 
enthält dann wiederum Zeiger auf die folgenden Windows. Exi¬ 
stieren mehrere Screens, dann bewahrt der erste Screen auch 
noch einen Zeiger auf den nächsten Screen auf, bei dem dann 
die gleiche Window-Verknüpfung abläuft wie eben aufgeführt. 
Zur besseren Übersicht hier noch eine Grafik: 
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Screen/MindoH-Linking 



Abbildung 3.1: Screen-/Window-Verknüpfung 


Die letzte anzusprechende Struktur-Definition mußte vorge¬ 
nommen werden, damit das Betriebssystem unsere neuen Funk¬ 
tionen, die Intuition-Funktionen, versteht. Diese sind nur durch 
die geöffnete Library zugänglich, von der wir die Adresse ken¬ 
nen müssen, die sich aber gerade im Pointer IntuitionBase be¬ 
findet. 

Als letztes sollte etwas zu den Kommentaren gesagt werden. Sie 
enthalten immer Angaben zum Autor und das Entstehungsdatum. 
Damit ist der Tag gemeint, an dem die ersten Zeilen geschrieben 
wurden. Es wird nicht bei jeder minimalen Veränderung gleich 
ein weiteres Datum hinzugefügt, es sei denn, daß eine elemen¬ 
tare Umgestaltung erforderlich war. In der Überschrift wird mit 
wenigen Worten der Sinn des Programms oder der Funktion do¬ 
kumentiert. Es empfiehlt sich, diese Methode zu übernehmen, 
denn Sie werden viele hilfreiche Funktionen darin erkennen. 
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3.1.2.3 Die Window-Struktur 


Nachdem wir das Listing besprochen haben, gilt das größte In¬ 
teresse der Window-Struktur, die das Betriebssystem für uns 
eingerichtet hat. Sie enthält wirklich alle benötigten Informatio¬ 
nen. Hier ist sie: 

struct Window 
C 


0x00 

00 

struct Window *NextWindow; 

0x04 

04 

SHORT LeftEdge; 

0x06 

06 

SHORT TopEdge; 

0x08 

08 

SHORT Width; 

OxOa 

10 

SHORT Height; 

OxOc 

12 

SHORT MouseY; 

OxOe 

14 

SHORT MouseX; 

0x10 

16 

SHORT MinWidth; 

0x12 

18 

SHORT MinHeight; 

0x14 

20 

USHORT MaxWidth; 

0x16 

22 

USHORT MaXHeight; 

0x18 

24 

ULONG Flags; 

0x1 c 

28 

struct Menu *MenuStrip; 

0x20 

32 

UBYTE nitle; 

0x24 

36 

struct Requester *FirstRequest; 

0x28 

40 

struct Requester *DMRequest; 

0x2C 

44 

SHORT ReqCount; 

0x2E 

46 

struct Screen *WScreen; 

0x32 

50 

struct RastPort *RPort; 

0x36 

54 

BYTE BorderLeft; 

0x37 

55 

BYTE BorderTop; 

0x38 

56 

BYTE BorderRight; 

0x39 

57 

BYTE BorderBottom; 

0x3A 

58 

struct RastPort *BorderRPort; 

0x3E 

62 

struct Gadget *FirstGadget; 

0x42 

66 

struct Window ’^Parent 

0x46 

70 

struct Window ♦Descendant; 

0x4A 

74 

USHORT *Pointer; 

0x4E 

78 

BYTE PtrHeight; 

0x4 F 

79 

BYTE PtrWidth; 

0x50 

80 

BYTE XOffset; 

0x51 

81 

BYTE YOffset; 

0x52 

82 

ULONG IDCHPFlags; 

0x56 

86 

struct MsgPort *UserPort; 

0x5A 

90 

struct MsgPort *WindowPort; 

0x5E 

94 

struct IntuiMessage *MessageKey; 

0x62 

98 

UBYTE DetailPen; 

0x63 

99 

UBYTE BlockPen; 

0x64 

100 

struct Image *CheckMark; 

0x68 

104 

UBYTE *ScreenTitle; 

0x6C 

108 

SHORT GZZMouseX; 

0x6E 

110 

SHORT GZZMouseY; 
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0x70 112 SHORT GZZUidth; 

0x72 1U SHORT GZZHeight; 

0x74 116 UBYTE *ExtData; 

0x78 120 BYTE »UserData; 

0x7C 124 struct Layer *WLayer; 

0x80 128 struct TextFont *lFont; 

0x84 132 

>; 

Wie auch bei der NewWindow-Struktur wurden vor die einzel¬ 
nen Variablen Offsets geschrieben, mit denen der Assembler- 
Programmierer oder auch ein debuggender C-Programmierer 
eine große Hilfe hat. 

Gehen wir nun die Parameter einzeln durch: 

*NextWindow 

Ein Zeiger auf die nächste Window-Struktur des Screens. Mit 
diesem Pointer wird die oben erklärte Verkettung bewerkstelligt. 

Le ft Ed ge, TopEdge 

Position des Windows auf dem Screen, wie in NewWindow defi¬ 
niert. 

Width, Height 

Ausdehnung des Fensters, wie es in der NewWindow-Struktur 
definiert wurde. 

MouseX, MouseY 

Mauskoordinaten relativ zur linken oberen Ecke des Windows. 
MinWidth, MinHeigth 

Über die NewWindow-Struktur initialisierte Minimalwerte. 

MaxWidth, MaxHeight 

Ebenfals initialisierte Maximalwerte. 

Flags 

Flag-Liste, wie sie in NewWindow initialisiert wurde. 
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*MenuStrip 

Zeiger auf die Menü-Struktur dieses Windows. Siehe Kapitel 3.8 
für nähere Informationen. Über NewWindow kann kein Menü 
eingesetzt werden. Dies geschieht nur über eine Funktion. 

*Titel 

Zeiger auf String, der den Titeltext des Windows enthält. 
*FirstRequester 

Zeiger auf den ersten Requester, der in dieses Window gesetzt 
wurde. Siehe dazu Kapitel Requester. 

*DMRequest 

Zeiger auf Double-Menu-Requester. Siehe "Menüs/Requester". 
ReqCount 

Zähler für Requester, die in diesem Window geöffnet wurden. 
*WScreen 

Zeiger auf den Screen, in dem dieses Window geöffnet wurde. 
*RPort 

Zeiger auf RastPort, der für dieses Window eingerichtet wurde. 

BorderLeft, BorderTop, BorderRight, BorderBottom 
Die Werte beschreiben die jeweilige Breite des Randes. 

*BorderRPort 

Zeiger auf den RastPort des Borders. Diese Variable wird bei 
GIMMEZEROZERO-Windows benutzt. 

*FirstGadget 

Zeiger auf das erste Gadget einer gelinkten Liste aller Gadgets 
dieses Windows. 
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*Parent, *Descendant 

Verkettung mit vorhergehendem und nachfolgendem Window zur 
Erleichterung der Arbeit beim öffnen und Schließen. 

*Pointer 

Zeiger auf die Grafik des Maus-Cursors dieses Fensters. Er kann 
für jedes Fenster beliebig definiert werden. 

PtrHeight, PtrWidth 

Größe des Maus-Cursors (X-Wert darf 16 nicht überschreiten). 
XOffset, YOffset 

Offsets, die den Punkt des Sprites angeben, an dem der 
Klickpunkt liegt. 

IDCMPFlags 

Die vom Programm gesetzten Flags, wie sie auch in der 
NewWindow-Struktur standen. 

*UserPort 

Message-Port zur Übermittlung von Daten. 

*WindowPort 

Message-Port zur Übermittlung von Daten. 

*MessageKey 

Message-Port für Intuitions-Nachrichten. 

DetailPen, BlockPen 

Farbstifte, wie sie in NewWindow definiert wurden. 


*CheckMark 

Zeiger auf den für die Menüs definierten Haken. 
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*ScreenTitle 

Zeiger auf den String, der den Screen-Titel darstellt. Er kann 
nur über die Window-Funktion SetWindowTitles() eingestellt 
werden. Erklärung siehe weiter unten. 

GZZMouseX, GZZMouseY 

Mauskoordinaten für GZZ-Window. Bei ihnen wird automatisch 
der Rand berücksichtigt und vom normalen Wert abgezogen. 

GZZWidth, GZZHeight 

Da auch die Breite und Höhe des Windows vom Rand des GZZ- 
Window abhängt, erfährt man die richtigen Maße am besten aus 
diesen Variablen. 

*ExtData 

Zeiger auf externe Datenstrukturen. Bisher wird er nicht ge¬ 
nutzt. 

*UserData 

Zeiger auf eine Datenstruktur, die vom Programmierer einge¬ 
richtet werden kann. 

*WLayer 

Zeiger auf die Layer-Struktur dieses Windows. Der gleiche Wert 
ist auch über RPort->Layer zu erreichen. 

*IFont 

Zeiger auf den Font, mit dem in diesem Window Intuition-Text 
ausgegeben werden. 

Die Window-Struktur enthält einige Zeiger auf sehr wichtige 
Intuition- und Grafik-Elemente. 
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Die folgende Grafik soll das noch einmal verdeutlichen: 


Intuition-WindoM-Linking 


Uorkbench 

Screen 


1, MindoM 


Z. MindoH 


n. MindoM 


Custon 

Screen 


MenuStrip 


‘HfirstRequester 


DMRequester 


FirstGadget 


RastPort 


BorderRastPort 


Custon 

Screen 


TC 




Abbildung 3.2: Intuition-Window-Linking 


An alle diese Werte kommt man ganz leicht heran! Wollen Sie 
z.B. die Breite Ihres GIMMEZEROZERO-Windows wissen, so 
schreiben Sie einfach: 

Breite = FirstWindow->GZZWidth; 

Umgekehrt ist es natürlich auch durchaus möglich, irgendeinen 
gewünschten Wert zu verändern. Sie wollen unbedingt eine neue 
Grafik für das CheckMark einsetzen. Dann brauchen Sie nur 
folgendes zu schreiben: 

FirstWindow->CheckMark = NeuesCheckHark; 

Später wird es sehr wichtig sein, daß Sie leicht auf die Werte 
unseres Windows zurückgreifen können, denn sonst könnte man 
nie die herrschenden Voraussetzungen überprüfen, die sicherlich 
eine nicht unwichtige Bedeutung für Reaktionen des Programms 
haben. 
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Doch kehren wir mit unseren Betrachtungen zu dem ersten Pro¬ 
gramm zurück. Sie werden an dem ersten Aufruf unseres Win¬ 
dows erkannt haben, wie einfach die Programmierung von In¬ 
tuition sein kann. Daran wird sich prinzipiell nichts ändern. Es 
bleibt nur die Frage, ob man sich noch durch das Listing arbei¬ 
ten kann, wenn wir vielleicht fünf Windows definieren werden. 
Abgesehen von der Länge steht einem sicherlich viel Arbeit ins 
Haus. Wir müßten eine Methode finden, mit der gerade die 
Struktur-Definition einfacher und nicht so schreibintensiv ge¬ 
macht wird. Dafür habe ich folgende Definition vorbereitet: 


struct NeuUindow FirstNeuUindow = 

{ 

160, 50, /* LeftEdge, TopEdge */ 

320, 200, /* Width, Height */ 

0, 1, /* DetailPen, BlockPen */ 

NULL, /* IDCMP Flags */ 

WINDOUDEPTH | /* Flags */ 

WINDOUSIZING I 
UlNDOUDRAG | 

UINDOUCLOSE | 

SMART_REFRESH, 

NULL, /* First Gadget */ 

NULL, /* CheckMark •/ 

(UBYTE *)"SystetTprogratnnierung Test", 

NULL, /• Screen */ 

NULL, /* BitMap V 

100, 50, /* Min Width, Height */ 

640, 256, /* Max Width, Height */ 

WBENCHSCREEN /* Typ */ 

>; 


... was auch noch bis auf die nackten Informationen gekürzt 
werden kann: 


struct NewWindou FirstNeuWindow = 

{ 

160, 50, 320, 200, 0, 1, NULL, 

WINDOWDEPTHjWINDOWSIZINGjWINDOWDRAG|WINDOWCLOSE|SMART REFRESH, 
NULL, NULL, (UBYTE *)"Systefflprograimiierung Test", 

NULL, NULL, 100, 50, 640, 256, WBENCHSCREEN 

>; 


Der Vorteil liegt klar auf der Hand: Sie haben wesentlich weni¬ 
ger zu schreiben, weil der Struktur-Name nur einmal aufgeführt 
werden muß. Ob Sie die Kommentare dahinter schreiben, bleibt 
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Ihnen überlassen, es empfiehlt sich aber wenigstens bei der er¬ 
sten NewWindow-Zuweisung. 

So wie Sie die Struktur hier gesehen haben, gehört sie natürlich 
vor die main()-Funktion. Damit ist sie allgemeingültig und je¬ 
dem Programmteil bekannt. Wollen Sie vielleicht einzelne Werte 
verändern, so bleibt Ihnen immer noch die alte Methode mit 
Zugriff auf jedes einzelne Element über dessen Namen. Sie 
müssen bei der Kurzschreibweise beachten, daß die Reihenfolge 
entscheidet, was Sie definieren! Durch Verwechslungen können 
leicht Programmabstürze entstehen. 


3.1.2.4 Eine Übersicht aiier Window-Funktionen 

Die Vorarbeit ist endlich geleistet, auf das Erreichte können wir 
nun aufbauen! Für die kleineren nun folgenden Demonstrationen 
bitte ich Sie, als Standard das Programm 1 zu verwenden. Dabei 
ist es unwesentlich, ob Sie nun die Struktur in der main()-Funk- 
tion oder davor definiert haben. Behalten Sie aber bitte zuerst 
die Parameter bei, damit wichtige Grundvoraussetzungen herr¬ 
schen. Es ist außerdem üblich und wesentlich einfacher zu 
handhaben, wenn Sie eine globale Strukturdefinition nach der 
zweiten Methode vornehmen. 

Die ersten beiden Intuition-Funktionen bezüglich der Windows 
haben wir schon kennengelernt. Zum öffnen benutzten wir die 
OpenWindowO- und zum Schließen die CloseWindow()-Funk- 
tion. Ihre Anwendung ist Ihnen bestimmt klar geworden, und 
auch die erwarteten Parameter sind nicht schwer zu behalten. 

Achten Sie in allen weiteren Programmen nur darauf, daß alle 
Windows, die einmal geöffnet wurden, auch wieder geschlossen 
werden. Denn endet ein Programm, ohne alle Windows zu 
schließen, so ist der Zeiger auf das verbleibende Window verlo¬ 
ren, und es wird bis zum Ausschalten des Computers (oder ei¬ 
nem Reset) bestehen bleiben. Ein eventueller Screen, auf dem es 
sich befindet, ließe sich dann auch nicht mehr schließen! 



Intuition und C für Fortgeschrittene 


241 


Sehen Sie sich einmal die weiteren unterstützenden Funktionen 
an. Da haben wir zuerst SetWindowTitles(). Mit ihr ist es mög¬ 
lich, den Titel eines Windows nach seinem Einrichten zu verän¬ 
dern. Um Ihnen das zu demonstrieren, fügen Sie bitte folgende 
Zeilen in Ihr Programm (das Standardprogramm 1) ein: 

(nach DelaydSOL)!) 

SetUindowTitles(FirstUindow, 

"Neuer Window Titel", "Auch der Screen hat jetzt einen Titel!"); 

DelaydSOL); 

Wie Sie bestimmt schon an den Texten erkannt haben, wird zu¬ 
erst dem Window eine neue Überschrift gegeben. Der zweite 
macht es möglich, daß auch der Screen eine Überschrift be¬ 
kommt. Wenn Sie nämlich ein Window anklicken, so erhält der 
Screen-Titel-Balken ein neues Aussehen. In den meisten Fällen, 
das Programm wurde von der Workbench gestartet, bekommt der 
Screen keinen besonderen Titel, so auch beim CLI nicht. Es wird 
einfach der Text "Workbench Screen" in die Leiste gesetzt. Als 
Programmierer steht es Ihnen aber frei, einen anderen Text zu 
wählen, der erscheinen soll, wenn Ihr Window aktiv ist. Das 
Format dieses Befehls sieht wie folgt aus: 

SetWindowTitles(Window, WindowTitel, ScreenTitel); 

-276 AO A1 A2 

Ein selbstverständlicher Parameter, der Pointer auf die Window- 
Struktur des bezeichneten Windows, wurde noch nicht näher 
ausgeführt. Ich meine aber, daß es selbstverständlich ist, anzuge¬ 
ben, auf welches der vielen möglichen Windows man sich be¬ 
zieht. Dieser wichtige Parameter darf bei keiner Window-Funk¬ 
tion fehlen! 

Die Texte werden natürlich nicht in ihrer Zeichenkettenform 
übergeben, sondern sind als Pointer auf einen String bereitzu¬ 
stellen. Doch diese Arbeit nimmt einem wie so vieles der Com¬ 
piler ab. 

Nach dem trockenen Durchspielen von SetWindowTitles() ist es 
Zeit, sich zu überlegen, bei welchen Anwendungen der Ge¬ 
brauch nützlich sein könnte. Denken Sie vielleicht einmal an 
eine Textverarbeitung. Sicherlich bearbeiten Sie dort mehrere 
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Texte hintereinander oder gleichzeitig. Es ist jedoch immer 
wichtig zu wissen, an welchem Dokument man gerade arbeitet. 
Es ist deshalb schon eine Selbstverständlichkeit, daß in der Ti¬ 
telleiste des Editor-Windows der Name des Textes erscheint, 
damit man immer darüber informiert ist. Als Zugabe schreiben 
manche Programmierer dort sogar noch den Pfad hinein. So ha¬ 
ben Sie Überblick, mit welcher Textdiskette Sie arbeiten. Einen 
Text in die Titelleiste des Screens zu schreiben, ist nur mit Hilfe 
von SetWindowTitlesO möglich. Über die NewWindow-Struktur 
wird es nicht unterstützt. 

Die Funktion SetWindowTitlesO kennt für beide Texte noch 
zwei Sonderangaben. Stellen Sie sich folgende Situation vor: Die 
Screen-Titelleiste wird von Ihrem Programm mit seinem Namen 
und einem Copyright-Vermerk versehen. Haben wir eine Text¬ 
verarbeitung vor uns, kommt es bestimmt mehrmals vor, daß ein 
anderer Text geladen wird, und so muß auch der Titel des Win¬ 
dows geändert werden, den des Screens wollen Sie aber gleich 
behalten. Dafür können Sie ganz einfach -1 anstelle des Pointers 
einsetzen. So sparen Sie die Arbeit, den Pointer, es könnte ja 
auch immer ein wechselnder Text sein, immer wieder rauszusu¬ 
chen. 

Die zweite Sondereinstellung gibt dem Programmierer die Mög¬ 
lichkeit, den Text einer der beiden Titelleisten oder auch beider 
zu löschen. Dies kann der Fall sein, um bei unserem Beispiel zu 
bleiben, wenn der Textspeicher geleert wurde und noch nichts 
Neues eingegeben oder geladen wurde. Setzen Sie dafür einfach 
den oder die Parameter gleich Null. 

Ich möchte Sie ermutigen, beide Einstellungen ruhig einmal 
auszuprobieren. Schreiben Sie dazu einige gewünschte Versionen 
in Ihr Programm, und verzögern Sie die Ausführung zwischen 
zwei Befehlen mit der Delay()-Funktion. 

Die nächste die Window-Handhabung unterstützende Funktion 
wurde erst in der Version 1.2 der "intuition.library" ergänzt. Sie 
macht es dem Programmierer möglich, zu gewünschten Zeit¬ 
punkten des Programmablaufs ein Window zu aktivieren. Die 
Funktion heißt ActivateWindow() (eine plausible englische 
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Übersetzung). Ihr wird als einziger Parameter der Zeiger auf die 
Window-Struktur übergeben. Probieren Sie es gleich einmal aus. 
Fügen Sie bitte folgende Zeilen in das Standardprogramm 1 ein 
(wir gehen wieder von der Orginalfassung aus, nicht von den 
Ergänzungen zum SetWindowTitlesO, die sie aber troztdem ab¬ 
speichern sollten): 

(nach DelaydSOD!) 

Act i vateUi ndow( F i rstUi ndow); 

DelaydSOD; 

Damit Sie überhaupt ein Ergebnis erkennen, wenn Sie das Pro¬ 
gramm ablaufen lassen, müssen Sie nach dem Erscheinen des 
Windows sofort irgendwo in den Screen oder auf ein anderes 
Window mit der linken Maustaste klicken. Jetzt ist Ihr Window 
deaktiviert, und nach einiger Zeit wird es automatisch aktiv ge¬ 
setzt. 


ActivateWindow(Winclow); 

-450 AO 

Der Befehl hat eine große Bedeutung für die Eingabe! Dazu 
müssen Sie wissen, daß Eingaben immer nur in das aktive Win¬ 
dow möglich sind. Fragt ein Programm ab, ob ein Window aktiv 
ist, das nicht aktiv sein soll, weil keine Eingaben gemacht wer¬ 
den dürfen, dann setzt es ein anderes aktiv. In diesem Fall ist es 
Ihnen nicht möglich, irgendwelche Informationen oder Anwei¬ 
sungen zu geben. Eine passende Anwendung finden Sie im Ka¬ 
pitel zur Informationsübermittlung "Abfrage der IDCMP-Flags". 

Aus welchem Grund auch immer könnte es einmal notwendig 
sein, die Position eines Windows zu verändern. Vielleicht muß 
ganz dringend ein neues Fenster an der gleichen Position geöff¬ 
net werden, und das alte soll noch vom Inhalt her erkennbar 
sein. Dann darf man die Arbeit nicht dem Benutzer überlassen, 
denn dieser Fall könnte öfter auf treten, und das würde ihn ver¬ 
ärgern. Wenn Sie also als Programmierer schon wissen, wann 
eine Positionsänderung unbedingt nötig ist, dann sollten Sie auf 
die MoveWindow()-Funktion zurückgreifen. Ihr übergeben wir 
zusätzlich zum Window-Pointer noch zwei relative Werte, die die 
Verschiebung in x- und y-Richtung angeben. 
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Aber gerade die Verschiebewerte, im weiteren Text mit Delta- 
Werten bezeichnet, bergen eine große Gefahr in sich. Wird näm¬ 
lich durch die Verschiebung das Window auch nur einen Pixel 
aus dem Screen geschoben, so stürzt das System ab. Wir müssen 
deshalb unser Programm beauftragen, die Delta-Werte zu über¬ 
prüfen. Dabei greifen wir auf die Informationen unserer Win¬ 
dow-Struktur zurück, in der ja die aktuelle Position gespeichert 
ist. Fügen Sie bitte folgende Zeilen in das Standardprogramm 1 
ein: 


(nach 0elay(180L)!) 

DeltaX = FirstUindou.LeftEdge; 

DeltaY = FirstWindow.TopEdge; 

MoveWindow(FirstWindow, -1*DeltaX, -l’^DeltaY); 

DelaydSOL); 

Bevor Sie dieses Programm starten können, müssen Sie noch die 
beiden Delta-Variablen als SHORT definieren! Würde das Pro¬ 
gramm dann endlich ausgeführt, so brächte es das neu geöffnete 
Window nach kurzer Zeit in die linke obere Ecke des Screens, 
denn es verschiebt es genau um die aktuelle Position zum Null¬ 
punkt. 

Sie können natürlich auch noch aufwendigere Verschiebungen 
programmieren, doch diese bot sich an, da böi ihr keine Abfra¬ 
gen zur Delta-Wert-Prüfung nötig sind. Achten Sie auch darauf, 
daß Sie nicht mit zu vielen Verschiebungen arbeiten, da diese 
sehr viel Zeit in Anspruch nehmen, besonders, wenn mehrere 
Windows in einem Screen offen sind. 

Zum Schluß noch das allgemeine Format der neuen Funktion: 

MoveUindoutMeinUindow, DeltaX, DettaY); 

-168 AO DO Dl 

Ein Befehl in ähnlicher Kategorie ist SizeWindow(). Es kann 
durchaus vom Programm erwünscht sein, das Format eines Win¬ 
dows zu ändern. Einmal in den Fällen, in denen es dem Benut¬ 
zer nicht gestattet worden ist, dieses selbst vorzunehmen, aber 
auch, wenn eine größere Arbeit vermieden werden soll. So bie¬ 
ten es gute Programme an, mit einem Gadget-Klick das ganze 
Arbeits-Window auf kleinste Größe zu bringen. Damit erspart 
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sich der Benutzer die Arbeit. Umgekehrt geht es natürlich auch. 
Dann wird zumeist in Verbindung mit MoveWindow() das ganze 
Fenster in die linke obere Ecke gebracht und auf die Größe des 
Screens vergrößert. 

Ich möchte hier nur das erste Beispiel vorstellen, denn für die 
letzten beiden ist schon im letzten Teil dieses Kapitels ein Bei¬ 
spielprogramm vorhanden. Ergänzen Sie deshalb Ihr Standard- 
Listing wie folgt: 

(nach Delay(180L)!) 

DeltaX = LeftEdge - MinWidth; 

DeltaY = TopEdge - MinHeight; 

SizeWindowCFirstWindow, -1*DeltaX, -1*DeltaY); 

Delay(180L); 

Auch hier müssen Sie zuerst die Variablen als SHORT definie¬ 
ren, da Sie sonst einen Error erhalten würden. 

Wichtig für diesen Window-Typ ist, daß Sie die MinWidth- und 
MinHeight-Variablen mit Werten belegt haben. Ansonsten tritt 
das Problem auf, daß das Window auf Pixelgröße verkleinert 
wird. Das ist aber nicht erwünscht. Dieser Fehler kann nur auf- 
treten, wenn Sie kein Sizing-Gadget gewählt haben und damit 
auch nicht die Minimum- und Maximum-Werte einstellen 
brauchen. Stellen Sie diese aber bitte dann trotzdem ein, denn 
wir möchten ja keinen Absturz provozieren. 

Das Format ähnelt sehr stark dem des MoveWindow()-Befehls: 

SizeUindowtMeinUindou, DeltaX, DeltaY); 

-288 AO DO Dl 

Achten Sie auch hier darauf, daß keine unmöglichen Werte für 
die Deltas eingesetzt werden. Das System stürzt bei jeder Über¬ 
tretung ab! Das Window darf weder kleiner gemacht werden als 
möglich noch größer, als der Screen es erlaubt. 

Da wir gerade bei der Größenveränderung sind, bietet es sich 
an, gleich noch die nächste Funktion anzusprechen. Mit Win- 
dowLimitsO können Sie nachträglich die Vergrößerungs- und 
Verkleinerungsgrenzen, die Limits, setzen. 
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Erkennt Ihr Programm z.B., daß es aus Speicherplatzgründen 
nicht mehr möglich sein kann, das Grafikfenster zu vergrößern, 
so korrigieren Sie einfach die Maximalwerte. Der Benutzer hat 
dann nur noch die Möglichkeit, sein Window zu verkleinern. Das 
Beispiel, das Sie wieder in unser Standardprogramm 1 einfügen 
können, läßt zuerst die über die NewWindow-Struktur einge¬ 
stellten Maximal- und Minimalwerte zu. Nach unserer bekannten 
Verzögerung, wird dieses Maximum verkleinert. Das Fenster läßt 
sich dann nicht mehr größer einsteilen. Am besten sehen Sie sich 
das Beispiel an und probieren es aus: 

(nach DelaydSOL)!) 

MinWidth = FirstWindow->MinWidth; 

MinHeight = Fi^stWindow->MinHe^ght; 

NewMaxUidth = 200; 

NewMaxHeight= 100; 

Erfolg = WindowLimits(FirstWindow, MinWidth, MinHeight, 

NewMaxUidth, NewMaxHeight); 

DelaydSOL); 

Bevor Sie diese Ergänzung ausprobieren können, definieren Sie 
die Grenzwerte als USHORT und den Ergebniswert als BOOL. 
Sie erhalten TRUE zurück, wenn kein Wert außerhalb der er¬ 
laubten Grenzen lag. 

Werden allerdings die Maximalwerte neu gesetzt, und, wenn das 
Fenster größer ist, als die neuen Werte erlauben, dann erhält das 
Programm den Wert FALSE als Ergebnis. Zum Abschluß hier 
noch das Befehlsformat in der allgemeinen Schreibweise: 

Erfolg = WindowLimits(MeinWindow, MinBreite, MinHöhe, 

DO -318 AO DO Dl 

MaxBreite, MaxHöhe); 

D2 D3 

Ein neu geöffnetes Window wird immer vor allen anderen pla¬ 
ziert. Daß dadurch andere verdeckt werden können, ist Ihnen 
sicherlich aus der täglichen Arbeit mit Intuition bekannt. Für 
den Programmierer stellt sich aber die Frage, wie er über sein 
Programm ein Fenster in den Hintergrund bringen kann, wenn 
es andere stören könnte, und wie er es wieder in den Vorder¬ 
grund bekommt. Der Benutzer regelt diesen Vorgang einfach 
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über die Depth-Arrangement-Gadgets. Dafür gibt es zwei Intui¬ 
tions-Funktionen: WindowToBackO und WindowToFront(). 

Beide Funktionen benötigen nur den Zeiger auf die Window- 
Struktur und führen dann ihre Aufgabe durch. Da Sie beim 
Starten aller Programme sicherlich das DOS-Window offen ha¬ 
ben, können wir gleich einmal ausprobieren, ob die Befehle 
funktionieren. Schreiben Sie folgende Zeilen zu unserem Stan¬ 
dardprogramm 1: 

(nach DelaydSOL)!) 

UindowToBack(FirstUindow); 

DelaydSOL); 

U 1 ndowToF ront(FirstWindow); 

DelaydSOL); 

Nach kurzer Zeit wird sich das neue Window hinter dem großen 
DOS-Fenster verstecken und dann wieder auftauchen. Hier noch 
das allgemeine Format: 

WindowT oBac k(Window); 

-306 AO 

WindowT oF ront(Window); 

-312 AO 


3.1.3 Programmsammlung "Anwendungen mit Windows" 

Im ersten Teil dieses Kapitels haben wir uns darauf beschränkt, 
ausführlich auf die Strukturen und Window-unterstützenden 
Funktionen einzugehen. Dieser abschließende Teil will nun nicht 
mehr Lehrbuchcharakter haben, sondern soll anhand von kleinen 
Beispielprogrammen demonstrieren, wie einfach es durch Intui¬ 
tion wird, seine Ausgabeeinheit Window zu bedienen. 

Es ist geplant, zu Anfang einige allgemeine Beispiele zu bringen, 
die sich überall einsetzen lassen. Wir bieten dadurch die Mög¬ 
lichkeit, noch einmal abzuwägen, wann welcher Window-Typ 
angebracht ist. 
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Im zweiten Teil sind Window-Strukturen und Programmteile zu 
finden, die für das geplante Großprojekt unseres Buches ent¬ 
worfen wurden. Alle werden in der Textverarbeitung, einem 
Editor, der hauptsächlich für C-Programme geschrieben wurde, 
benötigt. Haben Sie also Interesse an diesem Spitzeneditor, dann 
empfiehlt es sich, den Grundstock, der in diesem Kapitel zu 
finden ist, abzutippen. In den folgenden Unterkapiteln über 
Screens, Ausgabe, Gadgets usw. finden Sie dann Ergänzungen 
mit Beschreibung, wie Sie diese in das schon Vorhandene einfü- 
gen. Das ganze Intuition-Kapitel kann aber nicht einen fertigen 
Editor ausarbeiten, wir brauchen noch einiges an Programmier¬ 
kunst. Dazu finden Sie im dritten Teil, aufbauend auf unser In¬ 
tuition-Gerüst, Funktionen und Routinen, die sich mit der 
Textverarbeitung beschäftigen. 

Der dritte Abschnitt befaßt sich dann mit den restlichen kleinen 
Programmbeispielen, die schon im Intuition-Teil vollständig fer¬ 
tiggestellt werden können. Lassen Sie sich überraschen. 


3.1.3.1 Windows für jeden Zweck 

Wie schon erwähnt, finden Sie hier Beispiellistings, die Ihnen 
Anregungen für die eigene Programmierung geben sollen. Jedes 
Listing eignet sich für einen bestimmen Anwendungsbereich. Sie 
können dann ganz einfach, durch leichte Veränderung der Ein¬ 
stellungen, das Programm Ihren Bedürfnissen anpassen. 


Zeichenprogramm (allg. Grafikprogramme) 

Gehen wir für das Zeichenprogramm davon aus, daß der Screen, 
auf dem gezeichnet werden soll, die gewünschten Farbeinstellun¬ 
gen hat. Wir nehmen jetzt dazu die Workbench. Wenn Sie das 
zweite Kapitel durchgearbeitet haben, können Sie aber auch je¬ 
den anderen Screen öffnen. 

Da es von keiner Betriebssystemfunktion unterstützt wird, auf 
einen Screen zu zeichnen, müssen wir den Weg über die Win¬ 
dows gehen. Dabei soll das Window möglichst Screen-ähnlichen 
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Charakter haben: maximale Größe, vollkommen leere Fläche und 
verschiebbar in vertikaler Richtung. 


Unser Window kann natürlich die maximale Größe des Screens 
annehmen. Für die leere Fläche müssen wir dann einfach die 
Randbemalung abstellen. Dafür gibt es das BORDERLESS-Flag! 
Falls das Programm (Zeichenprogramm) aber andere Windows 
öffnet, kommen wir in Schwierigkeiten. Denn diese könnten ja 
hinter unser Window gelegt werden, womit sie dann nicht mehr 
erreichbar sind, weil unser Fenster keinen Rand mit Gadgets 
hat. Überall die Depth-Arrangement-Gadgets wegzulassen, wi¬ 
derspricht jedoch jeder guten Programmierkunst und wäre auch 
nicht benutzerfreundlich. Wir schalten einfach gleichzeitig noch 
BACKDROP ein, und schon haben wir ein Window mit den Ei¬ 
genschaften eines Screens! 


struct NewUindow 

FirstNewWindow = 


0, 0, 

/* LeftEdge, TopEdge 

*/ 

640, 256, 

/* Width, Height 

*/ 

0, 1, 

/* DetailPen, BlockPen 


NULL, 

/* IDCMP Flags 


BACKDROP I 
BORDERLESS | 
SMART REFRESH, 

/* Flags 

*/ 

NULL,“ 

/* First Gadget 

*/ 

NULL, 

/* CheckMark 

*/ 

NULL, 

/* Window Title 

*/ 

NULL, 

/♦ Screen 

*/ 

NULL, 

/* BitMap 

*/ 

0, 0, 

/* Min Width, Height 

*/ 

0, 0, 

/♦ Max Width, Height 

*/ 

WBENCHSCREEN 

>; 

/* Type 

♦/ 


Programm 3.2: Zeichenprogramm 


Sie finden hier kein ganzes Listing abgedruckt, weil es gar nicht 
nötig war, dieses zu tun. Setzen Sie einfach diese Struktur in 
unser Standardprogramm 1 ein. Dadurch, daß dieses Programm 
allgemein zusammengebaut wurde, ersparen wir uns Druckarbeit 
und somit Platz. Außerdem können Sie, wenn Sie das Programm 
extra abgespeichert haben, es einfach laden und die Struktur neu 
einsetzen. So müssen Sie nicht immer wieder alles abtippen, 
denn wir werden es sicherlich noch öfter gebrauchen. 
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Betrachten wir jetzt die Zusammensetzung der Struktur: Die Po¬ 
sition und Ausdehnung wurden entsprechend einem normalen 
Workbench-Screen gewählt. Das Window enthält kein einziges 
Gadget, ist dafür aber als BACKDROP und BORDERLESS de¬ 
finiert. Der Refresh-Mode wurde mit SMART_REFRESH ge¬ 
nau richtig ausgesucht, denn SUPER_BITMAP ist nur nötig, 
wenn Grafiken behandelt werden sollen, die größer als die Aus¬ 
maße .des Windows sind. Auf einen Titel wurde diesmal ganz 
verzichtet, damit keine Titelleiste erscheint. Somit haben wir, da 
ja auch keine Gadgets angewählt wurden, einen vollkommen 
leeren Bildschirm als Zeichenfläche. In diesem Fall ist es sogar 
gar nicht möglich, das Schließen vom Benutzer anzuweisen. Des¬ 
halb eignet sich die Methode mit der Verzögerung über Delay() 
wunderbar. 

Als einziges sichtbares Ärgernis tritt bloß die Titelleiste des 
Screens in Erscheinung. Sie überdeckt im Normalfall jedes 
BACKDROP-Window, was aber bei unserem Zeichenprogramm 
gar nicht erwünscht ist. Wir wollen eine vollkommen leere Zei¬ 
chenfläche durch unser Window bekommen. Dafür benutzen wir 
die Funktion ShowTitel(), mit der eingestellt werden kann, ob 
die Titelleiste des Screens gezeigt oder nicht gezeigt werden soll. 
Als Argument benötigen wir einen Zeiger auf den betreffenden 
Screen und den Aussagewert. Das folgende Hauptprogramm löst 
die Aufgabe, wenn Sie die beiden Funktionen hinzufügen: 

* * 

* Programm: Window für Grafikprogramm * 

* =====================:=====:==========: ♦ 

W * 

* Autor: Datum: Kommentar: * 

* _ _ _ ♦ 


* Wgb 06.12.1987 BACKDROP 

* BORDERLESS 



#include <exec/types.h> 

#include <intuition/intuition.h> 


struct IntuitionBase '*'IntuitionBase; 
struct Window *FirstWindow; 
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struct IntuiMessage *message; 


Struct NewUindow 

r 

FirstNewUindow = 


0, 0, 

/* LeftEdge, TopEdge 

*/ 

640. 256, 

/* Width, Height 

*/ 

0. 1, 

/* DetailPen, BlockPen V 

NULL, 

/* lOCMP Flags 

*/ 

WINDOWCLOSE j 

/* Flags 

*/ 


BACKDROP I 


BORDERLESS j 
SMART_REFRESH. 


NULL, 

/* 

First Gadget 

*/ 

NULL, 

/* 

CheckMark 

*/ 

NULL, 

/* 

Window Title 

*/ 

NULL, 

/* 

Screen 


NULL, 

/* 

BitMap 


0, 0, 

/* 

Hin Width, Height 

*/ 

0, 0, 

/* 

Hax Width, Height 


WBENCHSCREEN 

/* 

Type 

*/ 


>; 


mainO 

i 

Open_AU(); 

ShowTitle(FirstWindow->WScreen, FALSE); 

DelaydSOL); 

Close__AU(); 

exit(TRUE); 

> 


Programm 3.3: Zeichenprogramm II 

Als nächstes möchte ich Sie mit dem GIMMEZEROZERO-Typ 
der Windows bekannt machen. Wir verwenden dazu ein Pro¬ 
gramm, das zuerst ein ganz einfaches Window öffnet. Dieses 
Window wird aber erst dann geschlossen, wenn Sie das Close- 
Gadget betätigen. Damit kommen Sie endlich in den Genuß der 
Gadget-Abfrage. Wir erweitern dann das Programm, indem es. 
Ihnen im DOS-Window, über das Sie es ja gestartet haben, die 
Koordinaten der Maus ausgibt. Dann verändern Sie die Window- 
Struktur dahingehend, daß Sie jetzt einen GIMMEZEROZERO- 
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Typ initialisieren. Auch jetzt lassen Sie sich wieder nach dem 
Starten die Mauskoordinaten ausgeben. Siehe da, der Nullpunkt 
liegt jetzt unter der Titelleiste! 


y*************************************** 

* * 

* Programm: Window GIMME2ER02ER0 Test * 

* ================================;=== * 

* * 

* Autor: Datum: Komnfientar: * 

★ .-_ ★ 

* Wgb 16.10.1987 mit Gadget> * 

* Abfrage * 

* * 
************4r*******4r******************y 


#include <exec/types.h> 

# 1 nclude <intuition/intuit1on.h> 


struct IntuitionBase *IntuitionBase; 
struct Window *FirstWindow; 

struct IntuiMessage *message; 


I 


struct NewWindow FirstNewWindow = 
i 

160, 50, 

320, 200, 

0 , 1 , 

CLOSEWINDOW, 

WINDOWDEPTH j 
WINDOWSI2ING | 

WINDOWDRAG | 

WINDOWCLOSE j 
GIMME2ER02ER0 
SMART_REFRESH, 

NULL, 

NULL, 


/♦ LeftEdge, TopEdge */ 
/* Width, Height V 


/* 

/* 

/* 


/* 

/* 


DetailPen, BlockPen */ 


IDCMP Flags 
Flags 


First Gadget 
CheckMark 


(UBYTE *)"GIMME2ER02ER0 Test”, 


NULL, 

NULL, 

100, 50, 

640, 256, 
WBENCHSCREEN 
>; 


/* Screen 
/* BitMap 
/* Min Width, 
/* Max Width, 
/* Type 


Height 

Height 


*/ 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 


mainO 

i 

ULONG MessageClass; 
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USHORT Code; 

struct Message *GetMsg(); 

Open^AlU); 

FOREVER 

i 

if (message = (struct IntuiMessage *) 
GetMsg(FirstWindow->UserPort)) 
i 

MessageClass = message->Class; 

Code = message->Code; 

ReplyMsg(message); 
switch (MessageClass) 
i 

case CLOSEWINDOW : Close All(); 

exit(TRUE); 

break; 

> 

> 

> 

> 


Programm 3.4: Gadget-Abfrage 


Auch an dieses Listing fügen Sie bitte, wie bereits bekannt, die 
beiden allgemein definierten Open_All()- und Close_All()- 
Funktionen an. 

Bevor Sie das Programm compilieren und starten, möchte ich 
noch kurz auf die Abfrage des System-Gadgets eingehen. Zur 
Nachrichtenübermittlung benötigen wir eine Message-Struktur, 
die wir am Anfang definieren. Zusätzlich benötigen wir noch 
eine entsprechende Funktion, mit der wir uns Nachrichten holen 
können. Die Funktion GetMsgO liefert uns laut Definition den 
Pointer auf eine solche Datenstruktur. Es ist dann allgemein üb¬ 
lich, diese Nachricht zu unterteilen in MessageClass, die Her¬ 
kunft der Nachricht, und Code. Dieser Code wird gleich mitbe¬ 
rechnet, ist aber für unsere Bedürfnisse noch nicht erforderlich. 
In einer SWITCH-Abfrage wird dann schließlich getestet, ob es 
sich um eine Nachricht des Typs CLOSEWINDOW handet - der 
Wert wurde entsprechend im include-File definiert - und wenn 
ja, wird das Entsprechende ausgelöst. 
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Diese Methode läßt sich noch viel weiter ausnutzen, doch dazu 
gibt es mehrere Kapitel: "Gadgets", "Abfrage der IDCMP-Flags" 
und "Abfrage der Menüs". 

Um noch, wie es ja eigentlich unser Ziel war, die Mauskoordi¬ 
naten auszulesen, definieren wir zwei weitere Variablen: 


SHORT MX, My; 

Beide erhalten in der FOREVER-Schleife, noch bevor über IF 
abgefragt wird, ihren Wert zugewiesen durch: 

Mx = FirstWindow->MouseX; 

My = FirstWindow->MouseY; 

Und werden mit: 

printfC'X: Xd Y: %d\n", Mx, My); 

ausgegeben! Wenn Sie das Ergebnis unserer kleinen Exkursion 
betrachtet haben, schreiten wir zu den letzten Änderungen. 

Zuerst ergänzen Sie die NewWindow-Struktur um das Flag 
GIMMEZEROZERO. Dann definieren Sie zusätzlich die Vari¬ 
ablen Gx und Gy als SHORT und weisen ihnen nach Mx und 
My folgendermaßen die Werte zu: 

Gx = FirstU)tKlow->GZZMouseX; 

Gy = FirstWindow->GZZMouseY; 

Auch die printf-Zeile muß ergänzt werden! 

printfC'X: Xd Y: Xd ; Gx: Xd Gy: Xd\n", Mx, My, Gx, Gy); 

Wenn Sie jetzt das Programm laufen lassen, werden Sie einen 
Unterschied zwischen normalen und GIMMEZEROZERO-Win- 
dows erkannt haben! 

Aber betrachten Sie doch einmal Ihren Speicherplatz über die 
Workbench-Anzeige, wenn keines der beiden Programme von 
eben läuft. Notieren Sie sich den Wert! Starten Sie jetzt das erste 
Programm - die einfache Koordinatenausgabe - und schreiben 
Sie sich auch diese Speicheranzeige auf. (Sie erhalten diese. 
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wenn Sie irgendwo auf die Workbench-Fläche mit der linken 
Maustaste klicken.) Danach beenden Sie das erste Programm, in¬ 
dem Sie das Close-Gadget betätigen. Nach dem Starten des 
zweiten Compilats dürfte einiges weniger an Speicher vorhanden 
sein! 


3.1.3.2 Programmteile für Textverarbeitung 

Machen Sie sich bereit für das Spitzenprodukt deutscher Pro¬ 
grammierkunst, und folgen Sie mir in das Reich der Windows: 

Um uns die Arbeit für den Quelltext-Editor so einfach wie 
möglich zu machen, bereiten wir jetzt schon alle Teile vor, die 
gebraucht werden. Dafür müssen wir aber zuerst überlegen, was 
wir brauchen! Keine Angst, ich habe Ihnen die Arbeit abge¬ 
nommen, denn schließlich haben Sie sich ja deswegen das Buch 
gekauft. 

Für den Editor benötigen wir mindestens drei Windows. Das er¬ 
ste benötigen wir für die Textausgabe. Es wird als Editor-Win¬ 
dow bezeichnet. 

Das zweite soll uns helfen, die Speicher- und Ladeaktionen 
leichter zu gestalten. Wir richten darin eine File-Select-Box ein. 
In solch einer Box finden Sie alle File-Namen eines Inhaltsver¬ 
zeichnisses und können über die Maus den gewünschten aus¬ 
wählen. Eigentlich handelt es sich dabei um einen Requester, 
doch die Ergänzungen mit Gadgets und der Requester-Struktur 
nehmen wir erst später vor. Es ist nur wichtig, daß Sie schon das 
File haben, damit wir darauf zurückgreifen können. 

Das letzte Window heben wir uns als einfache Struktur auf, die 
wir für irgendwelche Nachrichten-Windows oder Requester be¬ 
nutzen. Hier ist es auch wieder nur wichtig, daß Sie sich ein 
entsprechendes File einrichten. 

Welche Einstellungen soll nun das Editor-Window haben? Um zu 
Anfang möglichst viel Text darzustellen, empfiehlt es sich, den 
ganzen Screen, hier den Workbench-Screen, für das Window zu 
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verwenden. Dieses sind dann auch gleich die Maximalwerte. Für 
das Minimum kann man sich eigentlich eigene Werte aussuchen, 
die nur so bedacht sein sollen, daß wenigstens noch das Sizing- 
Gadget zu erreichen ist. Als letztes sind noch die Flags interes¬ 
sant. Wählen wir am besten alle Gadgets für eine hohe Bedie¬ 
nerfreundlichkeit. Als Refresh-Mode würde ich SMART_ 
REFRESH empfehlen, da SUPER_BITMAP übertrieben ist und 
das Programm mit SIMPLE_REFRESH zu viel Arbeit hätte. 
Hier ist also die Window-Struktur: 

struct NewWindow EditorWindow = 


C 


o 

o 

/* LeftEdge, TopEdge 

*/ 

640 , 256, 

/* Width, Height 

*/ 

0. 1, 

/* DetailPen, BlockPen 


NULL, 

/♦ IDCMP Flags 

*/ 

WINDOWDEPTH j 

/* Flags 

*/ 

WINDOWSIZING 1 



WINDOWDRAG | 



WINDOWCLOSE j 



SMART REFRESH, 



NULL,“ 

/* First Gadget 


NULL, 

/* CheckMark 


(UBYTE *)"Systefnprogrammierung C-Editor”, 


NULL, 

/* Screen 

*/ 

NULL, 

/♦ BitMap 

*/ 

100, 50, 

/* Min Width, Height 

*/ 

640, 256, 

/* Max Width, Height 

*/ 

UBENCHSCREEN, 

/♦ Type 

*/ 


>; 


Struktur 3.1: Editor-Window 


Für die File-Select-Box gilt eigentlich das gleiche wie auch für 
das Editor-Window. Allerdings soll sie nicht den ganzen Screen 
einnehmen, um auch noch etwas vom Text sichtbar zu lassen. 
Als System-Gadgets sind nur noch WINDOWDEPTH und WIN- 
DOWDRAG erlaubt, weil WINDOWCLOSE durch ein anderes 
Gadget ersetzt wird und Sizing die ganze Programmierung we¬ 
sentlich komplizierter machen würde. Hier also diese Struktur: 


struct NewWindow FileUindow = 


t 

180, 50, 
250, 150, 
0 , 1 , 
NULL, 


/* LeftEdge, TopEdge */ 
/* Width, Height •/ 
/• DetailPen, BlockPen */ 
/* IDCMP Flags */ 
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WINDOUDEPTH j 
UINDOWDRAG j 

SMART REFRESH, 

/* Flags 

*/ 

NULL, 

/* First Gadget 

*/ 

NULL, 

/* CheckMark 

*/ 

(UBYTE *)"File-Select 

-Box", 


NULL, 

/* Screen 

*/ 

NULL, 

/* BitMap 

*/ 

0, 0, 

/* Min Width, Height 

*/ 

0, 0, 

/* Max Width, Height 

*/ 

WBENCHSCREEN, 

>; 

/* Type 

*/ 


Struktur 3.2: File-Select-Box 

Das letzte Window, das wir auf jeden Fall für die Textverarbei¬ 
tung benötigen, ist ein Nachrichten-Window. Es soll hauptsäch¬ 
lich für Fehlermeldungen oder ähnliches benutzt werden. Des¬ 
halb ist es noch etwas kleiner als unsere File-Select-Box. Außer¬ 
dem fehlen ihm alle System-Gadgets, da es nur gelesen und be¬ 
stätigt, aber nicht verschoben werden soll. Die Window-Struktur 
ist ziemlich einfach: 

struct NewUlndow NachrichtehWindow = 


< 


250, 100, 

/♦ 

LeftEdge, TopEdge 

*/ 

140, 80, 

!* 

Width, Height 

*/ 

0, 1, 

/* 

DetailPen, BlockPen */ 

NULL, 

/* 

IDCMP Flags 


NULL, 

/* 

Flags 


NULL, 

/* 

First Gadget 

*/ 

NULL, 

/* 

CheckMark 

*/ 

NULL, 

NULL, 

/* 

Screen 

*/ 

NULL, 

/* 

BitMap 

*/ 

0, 0, 

/* 

Min Width, Height 

*/ 

0, 0, 

/* 

Max Width, Height 


WBENCHSCREEN, 

/♦ 

Type 



>; 


Struktur 3.3: Nachrichten-Window 


3.1.3.3 Window für ein neues CU 

Da es noch mehr Gründe gibt, weshalb man ein Window benö¬ 
tigt, ist dieses Unterkapitel entstanden. 
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Es ist in Planung, einen kleinen Editor zu schreiben, mit dem 
man im CLI arbeiten kann. Somit entfällt die lästige und sehr 
störende Arbeit mit dem alten Editor. Dafür brauchen wir na¬ 
türlich auch ein Window! Das Hauptprogramm mit der Window- 
Struktur finden Sie gleich im Anschluß. 


^***4r************4r*********************** 

★ * 

* Programm: Aufbau eines neuen CLI-Ed * 

* =======r============================ * 

it * 

* Autor: Datum: Kommentar: * 

* _ _ __ * 

* Wgb 20.10.1987 nur das Window * 

* mit Abfrage * 

* ★ 

**************************************** j 


#include <exec/types.h> 

#include <intuition/intuition.h> 

struct IntuitionBase *IntuitionBase; 
struct Window *FirstWindow; 

struct IntuiMessage *message; 


struct NewWindow ConsoleWindow = 


< 


o 

o 

/* 

LeftEdge, TopEdge 


640, 101, 

/* 

Width, Height 

*/ 

2, 3, 

/* 

DetailPen, BlockPen */ 

NULL, 

/* 

IDCMP Flags 


WINDOWDEPTH j 

/* 

Flags 

*/ 

WINDOWSIZING j 




WINDOWDRAG | 




WINDOWCLOSE | 




ACTIVATE 1 




SMART REFRESH, 




NULL, 

/* 

First Gadget 

*/ 

NULL, 

/* 

CheckMark 


(UBYTE *)"Wgb Prod. 

presents BECKERshell". 


NULL, 

/* 

Screen 


NULL, 

/♦ 

BitMap 

*/ 

640, 50, 

/* Min Width, Height 

*/ 

640, 256, 

/* 

Max Width, Height 

*/ 

WBENCHSCREEN, 

/* Type 



>; 


main() 
C 
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ULONG MessageClass; 

USHORT Code; 

struct Message *GetMsg(); 

Open_AlU); 

FOREVER 

C 

if (message = (struct IntuiMessage *) 
GetMsg(FirstWindow->UserPort)) 
i 

MessageClass = message->Class; 

Code = message->Code; 

ReplyMsgCmessage); 
switch (MessageClass) 

C 

case CLOSEUINDOU : Close All(); 

exit(TRUE); 

break; 

> 

> 

> 

> 


* it 

* Funktion: Alles öffnen * 

* ==============:===================== * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ * 

* Wgb 20.10.1987 * 

* it 

* Keine Parameter ♦ 

* * 
*******************4r*******************y 


Open^AllO 

< 

struct Library *OpenLibrary(); 
struct Window *OpenWindow(); 

if (!(IntuitionBase = (struct IntuitionBase *) 
OpenLibrary(”intuition.library", OL))) 
i 

printf(“Keine Intuition Library gefunden!\n“); 

Close AllO; 

exit(FALSE); 

> 
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if (!(FirstWindow = (struct Window *) 

OpenUindow(&ConsoleUindow))) 

< 

pr1 ntf("Window will nicht aufgehen!\n"); 

Close AHO; 

exit(FALSE); 

> 

> 


* * 

* Funktion: Alles schließen * 

* ==========:========================= * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ * 

* Wgb 20.10.1987 * 

* * 

* Keine Parameter * 

★ 

************4r**************************^ 


Close_AllO 

C 

if (FirstWindow) 

CloseWindow(FirstWindow); 

if (IntuitionBase) 

CloseLibraryCIntuitionBase); 

> 


Programm 3.5: Neues CLI 


3.2 Screens, eine elementare Darstellungsgrundlage 

Bei den Windows haben wir viele Einstellungsfaktoren kennen¬ 
gelernt, mit denen das Aussehen wesentlich beeinflußt werden 
kann. Eine viel wichtigere Rolle spielen Screens. Jede Einstel¬ 
lung eines Windows steht in gewisser Abhängigkeit zu denen des 
Screens. Die Farbe, die Auflösung und auch die Lage lassen sich 
durch den Screen beeinflussen und sind nur durch ihn vollkom¬ 
men eindeutig definiert. 
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Wozu dient nun der Screen bei der Arbeit unter Intuition? Da 
der Screen elementare Parameter in sich birgt, wird er auch ele¬ 
mentare Bedeutung haben. Der Screen dient, um gleich auf die 
Frage zu antworten, im wesentlichen als Untergrund für visuelle 
Ausgaben aller Art. Doch die Ausgaben haben verschiedene 
Zwecke und unterliegen demnach auch ganz verschiedenen 
Grundvoraussetzungen. Nehmen wir dafür zwei krasse Beispiele, 
an denen es sicher deutlich wird: 

Zuerst eine Textverarbeitung. Der Hauptzweck der Bildschirm¬ 
ausgabe ist das lesbare Darstellen des Textes. Doch dazu benötigt 
man, wie es auch bei Büchern allgemein üblich ist, nur zwei 
Farben. Wichtig mag es aber sein, daß die Schrift mit einer ho¬ 
hen Punktauflösung ausgegeben wird, damit der Leser am Bild¬ 
schirm keine Augenschmerzen bekommt. 

Als zweites Beispiel soll eine vielfarbige Grafikausgabe dienen. 
Diese benötigt hauptsächlich, wie ja schon der erste Satz sagte, 
viele Farben. Die Auflösung ist zwar kein unwichtiges Faktum, 
doch gibt es Modi (z.B. HAM), bei denen sie gar nicht ins Ge¬ 
wicht fällt. 

Schon diese beiden Beispiele machen klar, daß es nötig ist, 
mehrere Grundvoraussetzungen für die Programme zu bieten. 
Der Amiga geht hier sogar noch einen Schritt weiter. Er erlaubt 
es dem Programmierer, durch Screens mehrere verschiedene 
Modi auf dem Bildschirme gleichzeitig auszugeben, wohingegen 
es üblich ist, nur einen darzustellen. 

Intuition unterstützt es nun, fast beliebig viele dieser Screens mit 
beliebig vielen verschiedenen Modi einzurichten. Prinzipiell läuft 
der Vorgang ähnlich wie bei den Windows ab. Die folgenden 
Seiten werden Ihnen darüber Auskunft geben. 


3.2.1 Die Möglichkeiten beim Öffnen eigener Screens 

Bei der Analyse der Screen-Eigenschaften wollen wir einen an¬ 
deren Weg gehen, als wir es bei den Windows gemacht haben. 
Hier war es nämlich durchaus möglich, daß Sie mehrere Typen 



262 


Das große C-Buch zum Amiga 


schon über die Workbench kennengelernt haben (Beispiele siehe 
Demo-Schublade). Screens werden aber im allgemeinen nicht 
besonders üppig von der Workbench angeboten, und so ist der 
Amiga-Besitzer leicht in dem Glauben, es gäbe nur seinen 
Workbench-Screen. Wir wissen aber nun, daß dem nicht so ist. 

Die Informationsübergabe läuft bei allen Betriebssystemroutinen 
über Strukturen. Deshalb gibt es für die Einrichtung eines neuen 
Screens, genauso wie es für die Einrichtung eines neuen Win¬ 
dows eine NewWindow-Struktur gab, eine NewScreen-Struktur. 


3.2.1.1 Die NewScreen-Struktur 

Wir wollen nun diese NewScreen-Struktur betrachten und daraus 
die einzelnen Einstellungen erarbeiten. Hier ist sie: 


struct NewScreen 

r 

0x00 

00 

SHORT LeftEdge; 

0x02 

02 

SHORT TopEdge; 

0x04 

04 

SHORT Width; 

0x06 

06 

SHORT Height; 

0x08 

08 

SHORT Oepth; 

OxOa 

10 

UBYTE DetailPen; 

0x00 

11 

UBYTE BlockPen; 

OxOc 

T2 

USHORT ViewNodes; 

OxOe 

14 

USHORT Type; 

0x10 

16 

struct TextAttr ‘Font; 

0x14 

20 

UBYTE *DefaultTitle; 

0x18 

24 

struct Gadget *Gadgets; 

0x1 c 

28 

struct BitMap *CustoinB)tMap; 

0x20 

32 



>; 

Auffallend sind, wie auch bei der NewWindow-Struktur, die er¬ 
sten vier Parameter. Sie haben genau die gleiche Bedeutung wie 
bei den Windows. Mit LeftEdge und TopEdge wird die Lage des 
Screens auf dem Bildschirm des Monitors bezeichnet. Bisher ist 
es aber nur möglich, die Lage vertikal zu verändern. LeftEdge 
wurde also nur aus Kompatibilitätsgründen implementiert, denn 
es könnte ja sein, daß Kickstart 1.6 auch das ermöglicht. Doch 
bisher ist der Video-Chip dazu einfach nicht in der Lage. 
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Mit Width und Height können wir angeben, wie viele Pixel der 
Screen breit und hoch sein soll. Dabei ist man durchaus nicht an 
die bekannten Auflösungswerte gebunden. Ein Screen kann auch 
nur 100 Pixel breit sein, dafür aber 300 Pixel hoch (im Non-In- 
terlace-Modus). Als Maximalwerte für jeden Screen sind 
720*452 Punkte erlaubt, die an den Rändern aus bildschirmtech¬ 
nischen Gründen dann aber nicht mehr scharf abgebildet werden 
können. 

Ein vollkommen neuer Parameter ist die Einstellung der "Tiefe" 
eines Screens. Hier stellen Sie ein, wie viele BitPlanes für einen 
Screen eingerichtet werden sollen. Damit wird gleichzeitig der 
Speicherverbrauch und die Farbanzahl bestimmt. Uns interessiert 
natürlich hauptsächlich die Farbanzahl, die in bestimmter Ab¬ 
hängigkeit zum Wert von Depth steht. Nach der folgenden For¬ 
mel läßt sich die endgültige Anzahl von Farben berechnen: Far- 
ben=2^Depth. 

Wir müssen dabei aber noch einige Einschränkungen berück¬ 
sichtigen, auf die ich bei ViewModes zurückkommen werde. 

Vorher sehen wir uns erst einmal die bekannten Einstellungen 
DetailPen und BlockPen an. Beim Window wurden damit die 
Farben bezeichnet, mit denen Intuition die grafische Gestaltung 
des Windows vornahm. Übertragen auf den Screen heißt es, daß 
Intuition durch die beiden Parameter mitgeteilt wird, mit wel¬ 
chen Farben die Titelleiste und die Depth-Arrangement-Gadgets 
gezeichnet werden sollen. 

Zu beachten ist, daß nur Farbnummern erlaubt sind, die durch 
Depth eingestellt wurden. Haben Sie z.B. eine Tiefe von 3 Bit- 
Planes zugelassen, so ist eine maximale Anzahl von 8 Farben 
möglich. Diese sind von 0 bis 7 durchnumeriert. Also kann der 
höchste Wert bei DetailPen oder BlockPen 7 betragen. Genauso 
verhält es sich auch bei den Windows, die ja vollkommen von 
den Screen-Einstellungen abhängig sind. 

Nach den Farbstiften folgt in der NewScreen-Struktur ein Flag 
namens ViewModes. Mit ihm können wir die wichtigste Einstel¬ 
lung vornehmen. Wie schon zu Anfang angesprochen wurde, ist 
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es durchaus normal, wenn verschiedene Programmtypen ver¬ 
schiedene Anforderungen stellen. So benötigt man für die Schrift 
eine relativ hohe Auflösung und kann bei Grafiken teilweise 
darauf verzichten. Dafür benutzen wir dieses Flag, mit dem wir 
noch einiges mehr einstellen können. 

Der Normalfall ist, daß Intuition eine Auflösung von maximal 
320 Punkten in der X-Richtung annimmt. Damit ist gemeint, 
daß in dem viereckigen Bereich unseres Bildschirms 320 Punkte 
auf der Horizontalen Platz finden. Diese Punkte sind relativ 
breit und auch gut mit dem Auge zu erkennen. Bei hoher Auf¬ 
lösung werden die Punktbreiten dann halbiert, und wir haben 
640 Punkte auf der Horizontalen. 

Ähnlich läuft es auf der. vertikalen Ebene. Normalerweise wer¬ 
den hier bei der PAL-Version des Amiga 256 Zeilen dargestellt. 
Auch hier läßt sich eine Verdoppelung einschalten, die aber 
durch ein anderes Verfahren realisiert wird. Der Elektronen¬ 
strahl der Bildröhre schreibt einfach noch einmal eine halbe 
Zeile versetzt über das Bild, diesmal aber mit anderen Bildin¬ 
formationen. Da das Verfahren hauptsächlich für Grafiken in¬ 
teressant ist, möchte ich Sie hier auf das Supergrafik-Buch von 
DATA BECKER aufmerksam machen, in dem Sie ausführliche 
Informationen finden. Dort werden auch die anderen Modi be¬ 
schrieben, auf die ich hier nicht weiter eingehen will, da sie den 
Rahmen des Buches sprengen würden. 

Als Abschluß hier noch Liste aller möglichen Einstellungen: 


Flag-Name 

Hex-Wert 

Beschreibung 

HI RES 

0x000080001 

Screen mit doppelter X-*Auflösung. 

LAGE 

0x000000041 

Screen mit doppelter Y-Auflösung. 

HAM 

0x000008001 

4096- F arben -Modus. 

EXTRA_HALFBRITE 

0x000000801 

64-Farben-Modus bei 5 BitPlanes. 


PFBA 


0x000000401 
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Flag-Name 


Hex-Wert 


Beschreibung 


DUALPF 
SPRITES 
VP HIDE 


0x000004001 

0x000040001 

0x000020001 


Dual-Playfield-Modus. 

Sprites können verwendet werden. 


GENL0CK_AUDI0 

GENL0CK__VIDE0 

Tabelle 33: 


0x000001001 

0x000000021 


ViewModes 


Bindet über die Hardware ein Video- 
Bild in die Grafik ein. 


Bevor wir nun zum nächsten Wert der Struktur kommen, möchte 
ich noch den Zusammenhang zwischen Depth und ViewModes 
erklären; Da der Video-Chip große Speicherbereiche für unsere 
Screens verwalten muß, ist er eigentlich schon überlastet. Des¬ 
halb darf man es ihm nicht übelnehmen, wenn er bei der Auf¬ 
lösung von 640 Punkten streikt und nicht mehr als 16 Farben 
zuläßt. Dafür können Sie aber mit 320 Punkten alle maximalen 
32 Farben darstellen. Wollen Sie noch mehr Farben, so ist dies 
nicht über die BitMap-Methode möglich, dafür gibt es den 
HAM-Modus. 

Als nächster Wert wird der Screen-Typ eingestellt. Darunter sind 
nur zwei Möglichkeiten zu verstehen: als erstes der Workbench- 
Screen, der nur vom System aus geöffnet wird, und als zweites 
der CustomScreen (Benutzer-Screen). Zu diesen zwei Flags ge¬ 
sellen sich noch drei weitere, mit denen wir Besonderheiten 
vermerken können. Intuition muß ja für die BitMaps Speicher 
organisieren. Dies können wir aber auch selber machen und mit 
einem später folgenden Parameter einstellen. Damit Intuition 
weiß, daß wir schon Grafikspeicher besorgt haben, müssen wir 
dafür das dritte Flag setzen. 

Mit dem vierten Flag ist es möglich, den neuen Screen hinter 
allen anderen zu öffnen. Somit kann man im Verborgenen z.B. 
eine Grafik aufbauen und braucht den Screen nicht erst im Vor¬ 
dergrund zu öffnen und dann in den Hintergrund zu bringen. 

Über das fünfte Flag können wir den Screen "lahmlegen". Das 
heißt, wir können es Intuition untersagen, die System-Gadgets 
oder die Titelleiste zu zeichnen. Allerdings muß dann vom Pro¬ 
gramm aus dafür gesorgt werden, daß der rechte Maus-Button 
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nicht benutzt werden kann. Dies ist über ein bestimmtes Flag 
möglich. Ansonsten würde die Titelleiste mit den Menüs ge¬ 
zeichnet werden, da aber kein Löschen erlaubt ist, würde die 
Leiste nicht wieder entfernt werden. 

Hier alle Flags im Überblick: 


Flag-Name 

Hex-Wert 

Beschreibung 

WBENCHSCREEN 

0x00000001L 

Screen-Typ. 

CUSTOMSCREEN 

OxOOOOOOOFL 


CUSTOMBITMAP 

0x000000401 

Eigene BitMap. 

SCREENBEHIND 

0x000000801 

Wird im Hintergrund geöffnet. 

SCREENQUIET 

OxOOOOOlOOL 

Ohne Gadgets. 

SHOWTITLE 

0x0000001OL 

Die beiden letsten Flags werden von 
Intuition selbst gesetst. 

BEEPING 

0x00000020L 

Screen blinkt. 

Tabelle 3.4: 

Screen-Typ 



Der Screen hat, genau wie auch jedes Window, eine Titelleiste, 
in der ein Text steht, den wir auch über das Window einstellen 
können. Ist aber kein Window aktiv, so muß die Leiste nicht 
unbedingt leer sein! Die nächsten beiden Parameter erlauben es, 
elementare Texteinstellungen vorzunehmen. 

Zuerst können Sie mit Font auf eine TextAttr-Struktur zeigen, 
mit der Sie den Zeichensatz bestimmen, der für den Screen-Titel 
und alle anderen Texte von Intuition verwendet wird. Möchten 
Sie aber den Zeichensatz übernehmen, den der Benutzer mit 
Preferences ausgewählt hat, so schreiben Sie anstatt des Zeigers 
den Wert Null an diese Stelle. 

Der zweite Wert ist ein einfacher Zeiger auf einen String. 
Schreiben Sie hier Null, wenn Sie keinen Titel-Text ausgedruckt 
haben möchten. 

Zu dem Pointer auf die Gadget-Struktur kann leider nur gesagt 
werden, daß er aus Kompatibilitätsgründen mit in die New- 
Screen-Struktur übernommen wurde. Leider ist es bisher nicht 
möglich, Custom-Gadgets an einen Screen zu hängen. Sie sollten 
den Wert deshalb immer mit Null initialisieren, denn sollte es 
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einmal möglich sein, dann enthielte die Struktur einen Wert, der 
im schlimmsten Falle zum Absturz führt. 

Den letzten Pointer hatte ich teilweise schon unter Type ange¬ 
sprochen. Er zeigt im Normalfall auf eine BitMap-Struktur, die 
vom Programm selbst initialisiert wurde. Wenn Sie diese Funk¬ 
tion nicht nutzen, so sollte der Wert Null eingetragen werden. 


3.2.1.2 Vorab das erste Screen-Listing 


Bevor wir uns die Screen-Struktur ansehen, die ja genauso wie 
auch bei den Windows von Intuition aus der NewScreen-Struktur 
eingerichtet wird, sollten Sie sich das folgende Listing ansehen. 
Damit gehen wir von der Theorie wenigstens für einen kleinen 
Augenblick zur Praxis über: 


* * * 

* Programm: Window auf Custom Screen * 

* * 

* Autor: Datum; Kommentar: * 

* _ w 

* Wgb 16.10.1987 einfacher Screen * 

* * 

* ★ 


#include <exec/types.h> 

#include <intuition/intuition.h> 


struct IntuitionBase *IntuitionBase; 
struct Screen *FirstScreen; 

struct Window *FirstWindow; 

struct IntuiMessage *message; 


struct NewScreen FirstNewScreen = 


C 


0 , 0 , 

640, 256, 

1 , 

0 , 1 , 

HIRES, 

CUSTOMSCREEN, 


/* LeftEdge, TopEdge V 
/* Width, Height */ 
/* Depth */ 
/* DetailPen, BlockPen V 
/* ViewModes V 
/* Type */ 
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NULL, 

/* Font 

*/ 

(UBYTE *)"Screen Test", 


NULL, 

/* Gadgets 

*/ 

NULL, 

>; 

/* CustomBitMap 

*/ 

‘uct NewWindow 

FirstNewWindow = 


160, 50, 

/* LeftEdge, TopEdge 

*/ 

320, 200, 

/* Width, Height 

*/ 

0, 1, 

/* DetailPen, BlockPen V 

CLOSEWINDOW, 

/* IDCMP Flags 

*/ 

WINDOWDEPTH | 

/* Flags 

*/ 

WINDOWSIZING 1 



WINDOWDRAG | 



WINDOWCLOSE j 



SMART REFRESH, 



NULL,“ 

/* First Gadget 

*/ 

NULL, 

/* CheckMark 


(UBYTE *)"Test 

Custom*Screen”, 


NULL, 

/* Screen (kommt noch) 

*/ 

NULL, 

/* BitMap 

*/ 

100, 50, 

/* Min Width, Height 

*/ 

640, 256, 

/* Max Width, Height 

*/ 

CUSTOMSCREEN, 

/* Type 



>; 


mainO 

i 

ULONG MessageClass; 

USHORT ccxie; 

struct Message *GetMsg(); 

Open_AU(); 

FOREVER 

i 

if (message = (struct IntuiMessage *) 
GetMsgC FirstWindow->UserPort)) 

C 

MessageClass = message*>Class; 
ccxie = message* >C(xle; 
ReplyMsg(message); 
switch (MessageClass) 

C 

case CLOSEWINDOW : Close All(); 

exit(TRUE); 

break; 

> 

> 
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^*********************************************** 
★ * 

* Funktion: Library, Screen und Window öffnen * 

* =========================================== * 

* * 

♦ Autor: Datum: Kommentar: * 

* _ _ __ * 

* Wgb 16.10.1987 * 

* * 

* Sr 


Open AUO 

c“ 

void *OpenLibrary(); 

struct Window *OpenWindow(); 
struct Screen *OpenScreen(); 

if (!(IntuitionBase = (struct IntuitionBase *) 
OpenLibraryC'intuition.library**, OL))) 

< 

printfC'Keine Intuition Library gefunden!\n''); 

Close AUO; 

exitCFALSE); 

> 

if (KFirstScreen = (struct Screen 
OpenScreen(&FirstNewScreen))) 
f 

printf("Screen hat keine Zeit!\n"); 

Close AUO; 
exit(FALSE); 

> 

FirstNewWindow.Screen = FirstScreen; 

if (l(Firstwindow = (struct Window *) 

OpenWindow(&FirstNewWindow))) 
f 

printf("Window will nicht aufgehen!\n"); 

Close AUO; 
exit(FALSE); 

> 

> 
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^*************************************** 

* * 

* Funktion: Alles Geöffnete schließen * 

* ==:r==:==:========;=:=:=======:===:======:== * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ ★ 

* Wgb 16.10.1987 Window, Screen * 

* und Intuition * 

* * 

*************«r****Sr********************^ 


Close__All() 

C 

if (Firstwindow) CloseWindow(FirstWindow); 

if (FirstScreen) CloseScreen(FirstScreen); 

if (IntuitionBase) CloseLibrary(IntuitionBase); 

> 


Programm 3.5: Window auf Custom-Screen 


Dokumentation 

Der Aufbau dieses Listings sollte Ihnen bekannt verkommen. 
Nach der allgemeinen Pointer- und Strukturendefinition folgt 
das Hauptprogramm, das am Anfang die Open_All()-Funktion 
aufruft und danach in eine Warteschleife verzweigt, die erst 
dann verlassen wird, wenn Sie das Close-Gadget betätigen. Dann 
wird nämlich das Programm über Close_All() beendet. Betrach¬ 
ten wir nun einzeln die vier großen Bereiche: 

Unter den Pointern finden wir jetzt auch einen für die Screen- 
Struktur. Er wird benötigt, um später dem Window "einge¬ 
pflanzt" zu werden. Vorher brauchen wir aber die NewScreen- 
Struktur, die einen einfachen Screen öffnet, der die gleichen Ei¬ 
genschaften hat wie auch die Workbench, allerdings mit der 
Ausnahme, daß wir nur zwei Farben, also eine BitPlane, an¬ 
gefordert haben. 

Das Hauptprogramm ist Ihnen so schon bekannt, denn die 
Gadget-Abfrage des Close-Gadgets wurde am Ende des Win¬ 
dow-Kapitels erklärt. 

Zu der Open_All()-Funktion ist zusätzlich noch das öffnen des 
Screens gekommen, das ja vor dem des Windows und nach dem 






Intuition und C für Fortgeschrittene 


271 


der Library abgewickelt werden muß, denn ohne die Library 
gibt es gar keine OpenScreen()-Funktion, und ohne Screen 
könnte das Window nicht geöffnet werden. In das Window wird 
nämlich vorher noch der Zeiger auf den CustomScreen einge¬ 
setzt. 

Die Close_AIl()-Routine schließt natürlich erst das Window, 
dann den Screen und erst dann die Library. Alles läuft in umge¬ 
kehrter Reihenfolge zum öffnen ab. 

Wenn Sie Lust haben, sollten Sie ruhig einmal einen oder zwei 
Parameter der NewScreen- oder NewWindow-Struktur verän¬ 
dern. Machen Sie aber zu Anfang nicht zu viele Änderungen, es 
geschieht dann oft, daß man einen entstandenen Fehler über¬ 
sieht. Wie wäre es mit zwei weiteren BitPlanes für unseren 
Screen und gleichzeitig mit anderen Farbstiften im Window? Sie 
können alle Farben von 0 bis 7 verwenden. 


3.2.1.3 Die Screen-Struktur 


Nach diesem Abstecher in die Programmierkunst kommen wir 
aber nicht daran vorbei, uns auch die von Intuition eingerichtete 
Screen-Struktur anzusehen. Sie enthält viele Werte, Zeiger und 
Flags, mit denen sich wunderbar arbeiten läßt. Hier deshalb die 
Struktur mit den Offsets: 

struct Screen 
C 


0x00 

00 

struct Screen *NextScreen; 

0x04 

04 

struct Window ‘FirstWindow; 

0x08 

08 

SHORT LeftEdge; 

OxOA 

10 

SHORT TopEdge; 

OxOC 

12 

SHORT Width; 

OxOE 

14 

SHORT Height; 

0x10 

16 

SHORT MouseY; 

0x12 

18 

SHORT MouseX; 

0x14 

20 

USHORT Flags; 

0x16 

22 

UBYTE *Title; 

OxiA 

26 

UBYTE ‘DefaultTitle; 

OxIE 

30 

BYTE BarHeight; 

0x1 F 

31 

BYTE BarVBorder; 

0x20 

32 

BYTE BarHBorder; 

0x21 

33 

BYTE MenuVBorder; 

0x22 

34 

BYTE MenuHBorder; 
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0x23 35 BYTE WBorTop; 

0x24 36 BYTE WBorLeft; 

0x25 37 BYTE WBorRight; 

0x26 38 BYTE UBorBottom; 

0x28 40 struct TextAttr *Font; 

0x2C 44 struct ViewPort ViewPort; 
i 

0x00 00 struct ViewPort *Next; 

0x04 04 struct ColorMap *ColorHap; 
0x08 08 struct CopList *DspIns; 
OxOG 12 struct CopList *SprIns; 
0x10 16 struct CopList *ClrIns; 


0x14 

20 

struct UCopList *UCopIns 

0x18 

24 

SHORT 

DUidth; 

OxIA 

26 

SHORT 

DHeight; 

OxIC 

28 

SHORT 

DxOffset; 

0x1 E 

30 

SHORT DyOffset; 

0x20 

32 

UWORD 

Modes; 

0x22 

34 

UBYTE 

SpritePriorities; 

0x23 

35 

UBYTE 

reserved; 

0x24 

36 

struct Raslnfo ^Raslnfo; 

0x28 

40 




>; 

0x54 84 struct RastPort RastPort; 
i 


0x00 

00 

struct Layer *Layer; 

0x04 

04 

struct BitMap *BitMap; 

0x08 

08 

USHORT *AreaPtrn; 

OxOC 

12 

struct TmpRas ♦TmpRas; 

0x10 

16 

struct AreaInfo *AreaInfoi 

0x14 

20 

struct Gelslnfo ♦Gelsinfo, 

0x18 

24 

UBYTE Mask; 

0x19 

25 

BYTE FgPen; 

OxIA 

26 

BYTE BgPen; 

OxIB 

27 

BYTE AOlPen; 

OxIC 

28 

BYTE DrawMode; 

OxID 

29 

BYTE AreaPtSz; 

OxIE 

30 

BYTE linpatent; 

0x1 F 

31 

BYTE dummy; 

0x20 

32 

USHORT Flags; 

0x22 

34 

USHORT LinePtrn; 

0x24 

36 

SHORT cp__x; 

0x26 

38 

SHORT cp y; 

0x28 

40 

UBYTE mintermsC8]; 

0x30 

48 

SHORT PenWidth; 

0x32 

50 

SHORT PenHeight; 

0x34 

52 

struct TextFont ♦Font; 

0x38 

56 

UBYTE AlgoStyle; 

0x39 

57 

UBYTE TxFlags; 

0x3A 

58 

UWORD TxHeight; 

0x3C 

60 

UUORD TxWidth; 

0x3E 

62 

UWORD TxBaseline; 

0x40 

64 

WORD TxSpacing; 

0x42 

66 

APTR ♦RP^User; 
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0x46 

70 

ULONG longreserved[2]; 

0x4E 

78 

UWORD wordreserved[7]; 

0x5C 

92 

UBYTE reserved[8]; 

0x64 

100 


>; 

0xB8 184 

struct BitMap BitMap; 

0x00 

00 

UWORD BytesPerRow; 

0x02 

02 

UWORD Rows; 

0x04 

04 

UBYTE Flags; 

0x05 

05 

UBYTE Depth; 

0x06 

06 

UWORD pad; 

0x08 

08 

PLANEPTR Planes[81; 

0x28 

40 


>; 

OxEO 224 

struct Layer_Info LayerInfo; 

0x00 

00 

Struct Layer *top_layer; 

0x04 

04 

struct Layer *check_lp; 

0x08 

08 

struct Layer *obs; 

OxOC 

12 

struct MinList FreeClipRects; 

0x18 

24 

struct SignalSemaphore Lock; 

0x3C 

60 

struct List gs^Head; 

0x4A 

74 

LONG longreserved; 

0x4E 

78 

UWORD Flags; 

0x50 

80 

BYTE fatten_count; 

0x51 

81 

BYTE LockLayersCount; 

0x52 

82 

UWORD LayerInfo extra^size; 

0x54 

84 

WORD *blitbuff; 

0x58 

88 

struct LayerInfo_extra *LayerInfo_extra; 

0x5C 

>; 

92 



0x13C 316 struct Gadget ‘FirstGadget; 

0x140 320 UBYTE DetailPen 
0x141 321 UBYTE BlockPen; 

0x142 322 USHORT SaveColorO; 

0x144 324 struct Layer ‘BarLayer; 

0x148 328 UBYTE ‘ExtData; 

0x14C 332 UBYTE »UserData; 

0x150 330 

>; 

Auch wenn dies die längste Intuition-Struktur ist, kommen wir 
doch nicht an ihr vorbei. Wenn man bedenkt, daß sich an dieser 
Struktur alle anderen orientieren, so sollten wir besondere Sorg¬ 
falt auf ihre Betrachtung legen. 


*NextScreen 

Wie die Windows werden auch alle geöffneten Screens miteinan¬ 
der verbunden. Der Linkpointer steht in dieser Variablen. 
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*FirstWindow 

Jeder Screen enthält hier den Pointer auf das erste Window, das 
in ihm geöffnet wurde. Die Windows haben dann unter sich 
wieder einen Linkpointer. 

LeftEdge, TopEdge, Width und Height 

Diese vier Werte sind schon bei der NewScreen-Struktur erklärt. 
MouseX, MouseY 

Wie auch bei den Windows finden Sie hier die Mauskoordinaten, 
aber natürlich in bezug auf unseren Screen. 

Flags 

Dieser Wert wird initialisiert, wie wir es in unserer NewScreen- 
Struktur gemacht haben. Im Verlauf der weiteren Anwendungen 
findet man hier aber noch zwei neue Flags: 

SHOWTITLE 

Dieses Flag wird gesetzt, wenn durch ShowTitleO die Titelleiste 
des Screens gezeigt werden soll. 

BEEPING 

Dieses Flag wird in der Zeit gesetzt, in der der Screen durch 
DisplayBeepO aufblinkt. 

*Title 

Genau wie bei den Windows steht hier ein Pointer auf den 
Titeltext-String. 

*DefaultTitle 

Dieser Pointer tritt in Aktion, wenn ein Window keinen Screen- 
Titel bestimmt hat. Dann verwendet Intuition den DefaultTitle. 

Die folgenden neun Variablen der Screen-Struktur gelten allge¬ 
mein auf alle Windows des Screens und den Screen selbst! 

BarHeight 

Gibt die Höhe einer Titelleiste in Bildschirmzeilen an. 
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BarVBorder 

Breite des vertikalen Randes. 

BarHBorder 

Breite des horizontalen Randes. 

MenuVBorder 

Breite des vertikalen Randes der Menüs. 

MenuHBorder 

Breite des horizontalen Menürandes. 

WBorTop 

Breite des oberen Window-Randes. 

WBorLeft 

Breite des linken Window-Randes. 

WBor Right 

Breite des rechten Window-Randes. 

WBorBottom 

Breite des unteren Window-Randes. 

*Font 

Zeiger auf den allgemein von Intuition zu benutzenden Font. 
Initialisiert durch NewScreen-Struktur. 

View Port 

Hier wird im Gegensatz zu allen anderen Struktureinbindungen 
nicht ein Pointer auf die Struktur aufgenommen, sondern die 
Struktur selbst. Der ViewPort; enthält Informationen zur Dar¬ 
stellung, die der Copper, der Video-Chip, benötigt. 

RastPort i 

Die RastPort-Struktur, die auch wieder vollkommen in die 
Screen-Struktur übernommmen wurde, dient zur Verwaltung des 
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Screens und enthält alle Informationen, die für ein Zeichnen auf 
dem Screen benötigt würden. Weitere Informationen zu diesen 
elementaren Grafikstrukturen im Supergrafik-Buch. 

BitMap 

Die dritte eingebundene Struktur enthält genauere Angaben zu 
der Zeichenfläche, der BitMap. Weiterhin findet man hier Poin¬ 
ter auf jede einzelne BitMap. 

Layerlnfo 

Layers sind die Grundlage der Window-Verwaltung. Diese Info- 
Struktur bildet nur den Anfang. 

*FirstGadget 

Als nächstes finden wir den Pseudo-Pointer auf die Custom- 
Gadgets des Screens wieder. Natürlich ist er hier genauso wenig 
unterstützt, wie er es bei der NewScreen-Struktur war. Warten 
wir dafür einfach Version 1.8 oder höhere ab! 

DetailPen, BlockPen 

Die zwei Zeichenstifte, die schon unter NewScreen und 
NewWindow erklärt wurden. 

SaveColorO 

Da bei einem Screen-Blinken die Hintergrundfarbe gewechselt 
wird, also Farbe 0, muß diese irgendwo zwischengespeichert 
werden. Das geschieht in dieser Variablen. 

*BarLayer 

Hier haben wir den Zeiger auf den Layer, Grafikspeicherbe¬ 
reich, in dem die Titelleiste des Screens aufbewahrt wird. 

*ExtData 

Zeiger auf externe Daten, die zusätzlich angelegt werden kön¬ 
nen. 
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*UserData 

Zeiger auf Daten, die vollständig vom Benutzer verwaltet wer¬ 
den können. 


3.2.1.4 Die Screen-Funktionen 

Wie Sie ja schon in dem Beispielprogramm kennengelernt haben, 
gibt es für Screens auch eine Open()- und eine CloseScreen()- 
Funktion. Die Parameter sind der Window-Funktion ähnlich: 
zuerst die New-Struktur und danach die von Intuition angelegte. 

Wie Sie aber bestimmt richtig vermutet haben, gibt es nicht nur 
eine Funktion zum öffnen und eine zum Schließen. Viele andere 
helfen dem Programmierer bei seiner Arbeit und machen die 
Gestaltung einfacher. Betrachten wir deshalb jede einzeln. 

So wird z.B. auch das Anklicken der Depth-Arrangement-Gad- 
gets über Befehle unterstützt. Mit ScreenToFrontO oder Screen- 
ToBackO können Sie jeden Screen, zu dem Sie einen Pointer be¬ 
sitzen, in den Vorder- oder Hintergrund bringen. Um Ihnen dies 
einmal demonstrieren zu können, entfernen Sie bitte aus unse¬ 
rem Screen-Beispielprogramm die Gadget-Abfrage. Das Haupt¬ 
programm sollte dann so aussehen: 

mainO 

i 

Open^AUO; 

DelaydSOL); 

Close AUO; 
exit(TRUE); 

> 

Die Delay()-Zeile mußte noch zusätzlich eingefügt werden, da¬ 
mit Sie auch etwas davon merken, daß ein neuer Screen mit 
Window geöffnet wurde. Alle Ergänzungen fügen Sie dann bitte 
nach dem Delay(180L); ein, wenn es nicht anders gesagt wird. 
Als erstes hier ein Beispiel für ScreenToBack() und Screen¬ 
ToFrontO: 
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ScreenT oBack(FirstScreen); 

DelaydSOL); 

ScreenT oF ront(FirstScreen); 

Es handelt sich hier zwar um ein ganz einfaches Beispiel, denn 
der Screen wird nur einmal in den Hintergrund gebracht und 
dann nach kurzer Zeit wieder nach vorne, doch Sie sollen ja nur 
die Funktionen kennenlernen. Hier erst einmal die allgemeine 
Funktionsschreibweise mit Parametern, Registerangaben und 
Funktions-Offset: 

ScreenToBack(Screen); 

•246 aO 

Sc reenToF ront(Sc reen); 

-252 AO 

Die gleichen Möglichkeiten, die für jeden CustomScreen vorge¬ 
sehen sind, lassen sich natürlich auch auf die Workbench über¬ 
tragen. Meistens hat man aber das Problem, daß man nicht im 
Besitz des Pointers auf den Workbench-Screen ist. Deswegen gibt 
es zwei weitere Funktionen, die das auch ohne Pointer erledigen: 

UBenchToBackO; 

-336 

WBenchToFront(); 

-342 

Fügen Sie diese drei Zeilen ein: 

WBenchToFrontO; 

DelaydSOL); 

WBenchToBackO; 

Von BASIC ist es Ihnen vielleicht bekannt: Sie versuchen, im 
Editor mit dem Cursor aus dem Textbereich "herauszulaufen", 
und der Bildschirm blinkt. Dieses Blinken ist eine gekoppelte 
Warnaktion, die von Intuition ausgegeben wird. Sowohl ein op¬ 
tisches Signal, das Bildschirmblinken, als auch ein akustisches 
Signal, der Piepton, wird von diesem Befehl ausgesendet. Die 
folgende Beispielroutine liefert fünf Warnsignale hintereinander: 
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for ( 1 = 1 ; i<6; i++) 

for (j=0; j<10000; j++); 

DisplayBeepCFirstScreen); 

Zum Starten des neuen Programms definieren Sie vorher noch 
die beiden Lauf variablen i und j als integer. Das Programm läßt 
danach fünfmal den neuen CustomScreen auf blinken. 

Möchte man alle Screens aufblinken lassen, weil z.B. dem Pro¬ 
gramm nicht bekannt ist, ob der betreffende Screen überhaupt 
im Vordergrund ist, dann kann man als Pointer auch NULL an- 
geben, um Intuition mitzuteilen, daß alle Screens blinken sollen. 

DisplayBeeptNULL); 

Zum Abschluß dieser Funktion noch das allgemeine Format: 

DisplayBeeptScreen); 

-96 AO 

Bei manchen Anwendungen kann es durchaus Vorkommen, daß 
nicht genügend Grafikspeicher zur Verfügung steht. Dies läßt 
sich auch durch eine Speichererweiterung nicht beheben, denn 
der Chip-RAM-Bereich kann nicht über 512 KByte ausgebaut 
werden. 

Nachdem man sich bei Commodore einige Gedanken zu diesem 
Thema gemacht hat, ist man zu dem Ergebnis gekommen, daß 
während eines Programmablaufs die Workbench nicht gebraucht 
wird, wenn das Programm einen eigenen Screen geöffnet. In 
solchen Fällen kann man den Workbench-Screen schließen. Die 
einzige Bedingung dafür ist, daß kein weiteres Programm läuft, 
das seine Ausgabe in einem Window der Workbench vornimmt. 
Ist diese Bedingung erfüllt, dann erlaubt es Intuition mit Close- 
WorkBenchO, den Arbeitstisch zu schließen. 

Wie schaffen wir es nun, ein Programm zu starten, ohne daß 
sich ein anderes auf der Workbench "breitmacht"? Leider können 
wir unser Programm nicht von dem CLI-Window aus starten, 
denn dieses CLI ist ein eigenständiges Programm, welches seine 
Ausgabe auf unserer Workbench macht. Deshalb besorgen wir 
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uns für unser Testprogramm ein Icon, so daß es auch über einen 
Doppelklick aufzurufen ist. 

Compilieren Sie bitte das Standardprogramm 2, nachdem Sie es 
um die folgenden Zeilen ergänzt haben, und sichern Sie es auf 
Diskette. Denken Sie aber daran, mit "startup.o" zu linken(!): 

Am Ende der Open_All()-Funktion nach öffnen des Windows: 

CloseWorkBench(); 

Am Anfang der Close_All()-Funktion: 

OpenWorkBench(); 

Jeder Screen, dessen Titelleiste nicht durch ein BACKDROP- 
Window verdeckt ist, kann vom User über die linke Maustaste 
vertikal verschoben werden. Genauso, wie man es auch bei Win¬ 
dows vom Programm aus übernehmen kann, erlaubt eine weitere 
Intuition-Funktion es auch, den Screen zu verschieben. Mit Mo- 
veScreenO und den entsprechenden Delta-Werten ist das kein 
Problem. 

Ich habe für Sie zwei Zeilen vorbereitet, die den Screen immer 
wieder nach oben schieben, wenn Sie ihn nach unten gezogen 
haben. Fügen Sie die Zeilen in das Standardprogramm 2 in die 
FOREVER-Schleife noch vor der Abfrage ein: 

if (FirstScreen->TopEdge != 0) 

MoveScreen(FirstScreen, OL, -1L); 

Das allgemeine Format von MoveScreen() habe ich auch gleich 
parat: 


MoveScreentScreen, DeltaX, DeltaY); 

-162 AO DO Dl 

Da der ShowTitle()-Befehl schon im Window-Kapitel erklärt 
worden ist, bleiben noch zwei Funktionen, die sich auf Screens 
beziehen. Da haben wir zuerst die Funktion GetScreenData(), 
durch sie erhalten wir einen Datenüberblick zum angegebenen 
Screen. 



Intuition und C für Fortgeschrittene 


281 


Sicherlich lassen sich alle Werte auch über einen einfachen 
Strukturzugriff abfragen, doch hat man dann nicht den Über¬ 
blick zu einem bestimmten Zeitpunkt, denn alle anderen Para¬ 
meter können sich ja währenddessen ändern! Also richten wir 
uns für diese Funktion einen Puffer ein, in dem später alle Da¬ 
ten untergebracht werden. Dann rufen wir die Funktion auf, 
und alle Parameter sind in unseren Speicherbereich übertragen. 
Besonders sinnvoll ist diese Anwendung, wenn man die Daten 
des Workbench-Screen besorgen möchte. Da wir in einem Flag 
den Typ des Screen angeben können, ist es ein einfaches, dort 
Workbench einzusetzen. So kommen wir auch an diese Daten, 
die sonst nicht so einfach zu erreichen sind. Da ein Beispiel 
ziemlich umfangreich ist, hier nur die allgemeinen Para¬ 
meterangaben: 

Succes = GetScreenData(Buffer, Size, Type, Screen); 

DO -426 AO DO D1 A1 

Über MakeScreenO können wir einen von Intuition verwalteten 
Screen manipulieren, ohne Konflikte zu bekommen. Nach dem 
Aufruf von MakeScreen() und der Übergabe eines Screen-Poin- 
ters wartet er, bis der Intuition-View nicht mehr verwendet 
wird, erledigt währenddessen über MakeVPort() die Arbeit und 
gibt danach den Intuition-View wieder frei. 

Sicherlich haben Sie die obige Aufführung der Tätigkeit von 
MakeScreen nicht gleich verstanden. Das dafür benötigte 
Grundwissen mag Ihnen vielleicht fehlen. Wenn Sie das Thema 
interessiert, so muß ich Sie auf das Supergrafik-Buch verweisen, 
in dem unter dem Stichwort MakeVPortO einige wissenswerte 
Informationen stehen, die einfach den Rahmen dieses Kapitels 
sprengen würden. Bitte haben Sie dafür Verständnis. Ich möchte 
nur der Vollständigkeit halber hier trotzdem das allgemeine 
Format liefern: 

MakeSc reen(Sc reen); 

-378 AO 

Damit sind alle Funktionen, die sich auf die Screens von Intui¬ 
tion beziehen, beschrieben. Ich hoffe, daß Ihnen die kleinen 
Beispiele zum Verständnis geholfen haben. Im letzten Abschnitt 
dieses Screen-Kapitels finden Sie noch einige Beispielpro- 
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gramme, die einerseits nur die Programmierung noch verdeutli¬ 
chen sollen und andererseits auch für unser Großprojekt benutzt 
werden können. Bei den allgemeinen Programmen finden Sie 
auch noch eines, mit dem Sie Ihre Workbench manipulieren 
können. Ich wünsche schon jetzt viel Spaß! 


3.2.2 Anwendungsbeispiele für Screens 

Abschließend möchte ich einige kleine Programme und ergän¬ 
zende Programmteile vorstellen, die Sie in Ihre schon bestehen¬ 
den Programme einfügen können. 

Leider haben wir hier lange nicht so viele Beispiele. Das liegt 
daran, daß Screens nur für spezielle Anwendungen benötigt 
werden. Da wir uns hier aber nur auf den Intuition-Aspekt 
konzentrieren, ist es nicht ganz so wichtig. 


3.2.2.1 Allgemeine Beispiele 

Unter dieser Überschrift möchte ich zu dem bekannten Thema 
Grafikprogramme zwei Screen-Beispiele liefern, die Ihnen viel¬ 
leicht Anregungen zu eigenen Programmen geben. 


Zuerst einen superhochauflösenden Screen mit nur einer Bit- 
Plane. Superhochauflösend heißt, daß er mit 640*512 Punkten 
auf einem PAL-Fernseher läuft. Weiterhin habe ich nur eine 
BitPlane angewählt, weil schon genügend Speicher durch die 
hohe Auflösung verlorengeht. Es ist nämlich immer zu beden¬ 
ken, daß ja maximal nur 512 KByte für Grafikspeicher zur 
Verfügung stehen, da nur dieser Teil von den Chips angespro¬ 
chen werden kann (CHIP_MEMORY). 


struct NewScreen SuperScreen = 
i 


0 , 0 , 

640, 512, 
1 , 

0 , 1 , 
HIRES I 
HAM, 


/* LeftEdge, TopEdge V 
/* Uidth, Height V 
/* Depth V 
/* DetailPen, BlockPen */ 
/* VieuModes V 
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CUSTOMSCREEN j 

SCREENQUIET, 

NULL, 

NULL, 

NULL, 

NULL 

>; 


Struktur 3.3: Super-Screen 


/* Type 

*/ 

/* Font 


/* Gadgets 

*/ 

/* CustomBitMap 

*/ 


Dieser Modus eignet sich außer für digitalisierte Bilder auch 
noch für Grafiken, die Sie in Ihrem Programm verwenden wol¬ 
len. Natürlich können Sie damit ganz besondere hochauflösende 
und komplexe Bilder darstellen. 


Im zweiten Beispiel möchte ich darauf eingehen, daß es ja nicht 
unbedingt nötig ist, auch wirklich die ganze Auflösung auszu¬ 
nutzen. So kann auch ein Interlace-Screen ganz normal mit 256 
Zeilen initialisiert werden. Er nimmt dann eben nur die Hälfte 
des Bildschirms ein. Unter diesem Gesichtspunkt sei noch er¬ 
wähnt, daß bei Verwendung eines Interlace-Screens jeder andere 
Screen, der dargestellt wird, mitflackert. Ein nicht immer wün¬ 
schenswerter Nebeneffekt. 


struct NewScreen Utility = 
L 


0, 200, 

/* 

LeftEdge, TopEdge 

*/ 

640, 56, 

/* 

Width, Height 

*/ 

2, 


Depth 

*/ 

2, 1, 

i* 

DetailPen, BlockPen */ 

HIRES, 

/* 

ViewHodes 

♦/ 

CUSTOMSCREEN, 

/* 

Type 

*/ 

NULL, /* 

(UBYTE *)"Utility-Screen", 

Font 

*/ 

NULL, 

/* 

Gadgets 

*/ 

NULL 

>; 

/* 

CustomBitMap 

*/ 


Struktur 3.4: Utility-Screen 


Die hier vorgestellte Struktur öffnet in den unteren 56 Zeilen 
des Workbench-Screen einen weiteren. Hier können Sie vielleicht 
ein BORDERLESS-Window hineinlegen, in dem mit Gadgets 
Hilfsfunktionen eines Utilities unterstützt werden. 
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3.2.2.2 Programmteil “Screen" für Textverarbeitung 

Wenn Sie unseren C-Quelltext-Editor während der Arbeit mit 
dem Compiler laufen lassen, so kann es wünschenswert sein, daß 
er nach dem Editieren vollkommen vom Screen entfernt wird, 
weil z.B. auf der Workbench schon zu viele Windows geöffnet 
wurden und die Verarbeitungszeit somit ziemlich lange dauert. 
In solch einem Fall ist es geeignet, für ein neues Programm 
einen neuen Screen zu öffnen. Dann können Sie sich bei Bedarf 
vom Programm trennen und auf der Workbench ungestört Wei¬ 
terarbeiten. 

Die vorliegende Struktur ist besonders für eine Textverarbeitung 
eingerichtet. Sie nimmt nur eine BitPlane in Anspruch, damit 
möglichst wenig Speicher verbraucht wird. Dies müßte ausrei¬ 
chen, denn Farben sind im Text ja nicht unbedingt nötig. Aller¬ 
dings wird die hohe Auflösung angewählt, damit man einen gut 
leserlichen Text bekommt. 


struct NewScreen EditorScreen = 

{ 

0, 0, /* LeftEdge, TopEdge */ 

640, 256, /* Uidth, Height */ 

1, /* Depth */ 

1, 0, /* DetailPen, BlockPen */ 

HIRES, /* ViewModes */ 

CUSTOMSCREEN, /* Type */ 

NULL, /• Font */ 

(UBYTE *)"DATA BECKER C-Editor Screen", 

NULL, /* Gadgets */ 

NULL, /* CustomBitMap */ 

>; 


Struktur 3.5: Editor-Screen 


3.3 Ausgabe - denn ohne geht es nicht 

Sie sind nach dem Abschluß des 2. Unterkapitels über alle Fä¬ 
higkeiten der Intuition-Screens und -Windows informiert. Wie 
man sie öffnet und schließt und auch, wie man über andere 
Funktionen mit ihnen arbeitet. 
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Es ist aber nicht unbedingt der Sinn der Screens und Windows, 
einfach auf dem Bildschirm zu verbleiben und auf nichts weiter 
zu warten, als vom Benutzer hin- und hergeschoben zu werden. 

Ganz am Anfang hatte ich schon erwähnt, daß die Windows die 
Grundlage für jede Ein- und Ausgabe sind. Die Screens dienen 
nur dazu, eine Unterteilung vorzunehmen und festzulegen, wel¬ 
che elementaren Eigenschaften die Windows haben. Diese haben 
wir festgelegt, und wir können einen Screen einrichten. Wie man 
mit Windows umgeht, ist uns auch hinreichend bekannt. Aber 
wie steuert man die Ein- und Ausgabe? 

Wir werden uns in diesem Unterkapitel mit der Ausgabe be¬ 
schäftigen. Der Amiga bietet zwei Arten der Ausgabe. Am 
grundlegendsten sind die Ausgabefunktionen der "graphics.li- 
brary". Sie bietet den gesamten Standard der Ausgabefunktionen. 

Die zweite Möglichkeit wird von der "intuition.library" unter¬ 
stützt. Sie bietet nur drei verschiedene Ausgabefunktionen, die 
aber ausreichend sind, um alle weiteren Elemente darauf aufzu¬ 
bauen. Alle Kommunikationselemente wie Gadget, Requester 
und Menüs greifen auf die Hilfe der drei Grafikfunktionen von 
Intuition zurück. 

Sie sehen daran, wie wichtig es ist, daß wir uns jetzt damit be¬ 
schäftigen. Sie werden später begeistert sein, wie einfach sich 
durch das Baukastensystem von Intuition die komplexesten Ob¬ 
jekte aufbauen lassen. 

Außerdem möchten Sie doch sicherlich endlich einmal die Win¬ 
dows benutzen, die wir immer geöffnet haben, aber nie für et¬ 
was verwendeten. 


3.3.1 Textausgabe, unsere wichtigste Kommunikation 

Wir werden jetzt Schritt für Schritt die einzelnen Ausgabemög¬ 
lichkeiten durchgehen. Dazu nehmen wir zuerst die Textausgabe, 
weil sie die wichtigste Kommunikation unter den Menschen 
darstellt. 
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Es ist zu Anfang wichtig zu wissen, welche Einstellungen wir an 
unserem Text vornehmen können. Sie sind leicht zu verstehen. 


3.3.1.1 Position, Farbe, Zeichenmodus... 

Zuerst einmal die Position. Wir können in bezug auf unser Fen¬ 
ster punktgenau festlegen, wo der Text geschrieben werden soll. 
Weiterhin können wir sowohl für den Hintergrund als auch für 
den Vordergrund (die Textlinien selbst) die Zeichenfarbe be¬ 
stimmen. Hier greifen wir zurück auf eine bestimmte Anzahl 
von Farbstiften, die uns durch den Screen bereitgestellt werden. 
Eine Sonderrolle spielt der Farbstift mit der Nummer -1 (OxFF)! 
Bei seiner Auswahl wird mit der Default-Farbe des Windows 
gezeichnet. 

Wie es Ihnen vielleicht schon bekannt ist, gibt es verschiedene 
Modi, mit denen das Betriebssystem seine Ausgabe vornehmen 
kann. 

Der erste Modus betrachtet nur das zu Zeichnende selbst und 
nicht den Hintergrund. Auf unseren Text bezogen hieße das, 
daß nur die Textlinien selbst, nicht aber der Schrifthintergrund 
ausgegeben wird. Dadurch kann man seine Zerstörung vermei¬ 
den. Den Modus bezeichnet man als JAMl. Nur die Farbe 1 
wird in die Grafik geJAMt. 

Im zweiten Modus benutzt Intuition beide Stifte, um sowohl den 
Hintergrund als auch die Schrift auszugeben. Der Modus heißt 
JAM2, weil beide Farben gezeichnet werden. 

Der dritte Modus gleicht im großen und ganzen dem zweiten, 
mit dem Unterschied, daß beim Zeichnen die Farbstifte ver¬ 
tauscht werden. Eigentlich könnten Sie natürlich auch die Num¬ 
mern der beiden Farbstifte selbst vertauschen. Wir benötigen 
INVERSEVID aber für die Default-Farben, die mit -1 (OxFF) 
gekennzeichnet werden und bei denen ein Vertauschen dann 
nicht mehr möglich ist. 
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Modus Nummer drei arbeitet ähnlich wie eins, doch wird ent¬ 
sprechend des Untergrundes gezeichnet. Jeder schon gesetzte 
Punkt wird gelöscht und jeder gelöschte Punkt wird gesetzt. 

Hier ist noch einmal eine zusammenfassende Tabelle: 

Zeichenmodus Beschreibung 

JAMl Nur Farbstift 1 wird benutst. 

JAM2 Beide Farbstifte werden verwendet. 

INVERSEVID Wie JAM2, mit vertauschten Stiften. 

COMPLEMENT Wie JAMl, gelöscht wird gesetst und umgekehrt. 


Tabelle 3.5: DrawModes 


Mit der letzten Texteinstellung können Sie sich einen beliebigen 
Zeichensatz aussuchen, der Ihnen als TextAttr-Struktur vorliegt. 


3.3.1.2 Die IntuiText-Struktur 

Wie üblich, werden bei Intuition die Einstellungen in einer 
Struktur zusammengefaßt, unsere sieht dann wie folgt aus: 

struct IntuiText 
{ 

0x00 00 UBYTE FrontPen; 

0x01 01 UBYTE BackPen; 

0x02 02 UBYTE DrawMode; 

0x03 03 SHORT LeftEdge; 

0x05 05 SHORT TopEdga; 

0x07 07 struct TextAttr *ITextFont; 

OxOB 11 UBYTE *IText; 

OxOF 15 struct IntuiText *NextText; 

0x13 19 

>; 


Noch nicht besprochen sind die letzten beiden Elemente der 
Struktur. IText stellt einen Pointer auf einen String dar. Sie 
wissen ja, daß man unter einem String eine Zeichenkette ver¬ 
steht, die mit einem Null-Byte abgeschlossen ist. 

Mit dem letzten Pointer NextText bietet einem das System die 
Möglichkeit, mehrere solcher IntuiText-Strukturen zu einer lan- 
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gen Kette zusammenzufügen. Der Vorteil liegt dann im Aufruf 
der Ausgabe. Diese beschränkt sich dann nämlich nicht mehr auf 
eine Zeile oder eine Farbeinstellung, sondern ist für jeden Ein¬ 
zeltext vollständig neu einstellbar. Somit erreicht man höchste 
Flexibilität auch bei nur einem Funktionsaufruf. 


3.3.1.3 Der Zeichensatz macht alles interessanter 

Der einzige Parameter, den wir noch nicht genauer besprochen 
haben, ist der Zeichensatz. Dafür läßt sich jeder auf der 
Workbench-Diskette vorhandene nehmen. Allerdings bietet In¬ 
tuition eine Sondereinstellung. 

Sie sollten es noch aus dem Screen- und Window-Kapitel in Er¬ 
innerung haben, daß man für jeden Screen und für jedes Win¬ 
dow einen sog. Default-Font einstellen kann. Wenn wir nun 
diesen Font verwenden möchten - meistens wird er dann ja 
durch Preferences eingestellt - so schreiben wir statt des Poin¬ 
ters einfach den Wert Null dort hinein. 

Es ist natürlich auch möglich und eigentlich vorgesehen, daß 
man sich über die "diskfont.library" einen eigenen Zeichensatz 
besorgt, der dann hier verwendet wird. Verwenden Sie aber nur 
die beiden ROM-Fonts, damit erstens die Leserlichkeit und 
zweitens ein allgemeines Bild erhalten bleibt. Die Zeichensätze 
sind außerdem immer zu erreichen und haben Standard-Maße, 
auf die Sie sich im Programm verlassen können (z.B. bei den 
Menütexten). 

Für die Auswahl der beiden ROM-Fonts, aber auch jedes ande¬ 
ren, benötigen wir zuerst einmal die schon erwähnte TextAttr- 
Struktur, mit deren Hilfe sich sowohl der Font als auch seine 
Eigenschaften bestimmen lassen. Diese Struktur sieht wie folgt 
aus: 


struct TextAttr 

0x00 00 STRPTR ta_Naine; 
0x04 04 UWORD ta_YSize; 
0x06 06 UBYTE ta Style; 
0x07 07 UBYTE ta_Flags; 
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0x08 08 
>; 

In ta_Name wird ein Pointer auf einen String festgehalten, der 
den Namen unseres Fonts enthält. Wenn wir mit den ROM- 
Fonts arbeiten, so setzen wir "topaz.font" ein. Achten Sie bitte 
darauf, daß der Name vollständig in kleinen Buchstaben ge¬ 
schrieben wird, damit ihn das Betriebssystem erkennt, denn das 
achtet sehr genau auf die "Rechtschreibung". Haben Sie mit der 
"diskfont.library" zusätzlich noch andere Fonts geöffnet, so kön¬ 
nen Sie natürlich auch auf diese zurückgreifen. 

Mit dem nächsten Wert stellt man die Höhe des Fonts in Pixel 
ein. Sie bestimmen damit die Größe des Fonts und auch die 
Anzahl der Zeichen pro Zeile. Für unsere ROM-Fonts gibt es da 
zwei Möglichkeiten; 

Fonl-Size Zeichen Höhe 

TOPAZ_SIXTY Sechcig Zeichen bei 640 Punkten = 9 Pixel. 

TOPAZ_EIGHTY Achtsig Zeichen bei 640 Punkten = 8 Pixel. 

Tabelle 3.6: Standardzeichensätze 


Als nächsten Parameter enthält die TextAttr-Struktur ta_Style, 
mit dem der sog. Softstyle eingestellt werden kann. Darunter 
versteht man die Möglichkeit, einen vorhandenen Normalzei¬ 
chensatz über Rechenalgorithmen zu beeinflussen. Dadurch läßt 
sich zusätzlich Unterstreichen, Kursivschrift, Fettschrift und 
Breitschrift realisieren. Folgende Flags stehen Ihnen zur Verfü¬ 
gung und sind auch untereinander kombinierbar: 


Flag-Name 


Hex-Wert Bedeutung 


FS__N0RMAL 

0x00 

FSFJTALIC 

0x04 

FSF_B0LD 

0x02 

FSF_UNDERLINED 

0x01 

fsf"extended 

0x08 


Keine Beeinflussung 

Kursivschrift 

Fettschrift 

Unterstrichen 

Breitschrift 


Tabelle 3.7: Arithmetische Textveränderung 


Im letzten Wert unserer Struktur geben wir mit weiteren Flags 
noch zusätzliche Informationen zu unserem Zeichensatz. Diese 
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Flags tragen den Namen "Font Preference Flags" und lassen noch 
einige grundsätzliche Einstellungen zu. Uns interessieren davon 
nur zwei. In ihnen wird nämlich angegeben, von wo Intuition 
sich den Font besorgen soll. Zur Auswahl stehen da die Disk- 
Fonts und die ROM-Fonts. Da der "topaz.font" im ROM liegt, 
stellen wir natürlich auch das ein: 


Flag’Name 

Hex-Wert 

Bedeutung 

FPF^ROMFONT 

0x01 

Font ist im ROM eu suchen. 

FPF^DISKFONT 

0x02 

Font wurde von Disk geladen. 

FPF~REVPATH 

0x04 


FPF_TALLDOT 

0x08 


FPF_WIDEDOT 

0x10 


FPF_PROPORTIONAL 

0x20 


FPF^DESIGNED 

0x40 


FPF__REMOVED 

0x80 


Tabelle 3.8: FontTyp 




Möchten wir nun ganz bestimmt auf den "topaz.font" zurück¬ 
greifen, mit einer Zeichenzahl von 80 pro Zeile und einem ganz 
normalen Aussehen, dann sähe unsere Struktur so aus: 


struct TextAttr TestFont = 
i 

(STRPTR)''topaz.font'', 

TOPAZ^EIGHTY, 

FS_NORMAL, 

FPF_R0MF0NT 

>; 


3.3.1.4 PrintIText, die Ausgabe kann beginnen 

Nachdem schon fast zu ausführlich auf die einzelnen Parameter 
eingegangen worden ist, ist es endlich Zeit, auch mit der 
IntuiText-Struktur zu arbeiten. 

Sie erkennen, daß für die Ausgabe des IntuiTextes die Funktion 
PrintIText gebraucht wird. Wir benötigen weiterhin noch ein 
Argument, welches wir uns aus dem Window, in das die Aus¬ 
gabe erfolgen soll, besorgen müssen. Unser Argument ist der 
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RastPort, ohne den es nicht möglich ist, irgendwelche Ausgaben 
zu tätigen. 

Mit der folgenden Definition und Deklarierungszeile ist es aber 
kein Problem: 

struct RastPort ♦MeinesWindowsRastPort; 

MeinesWindowsRastPort = MeinWindow->RPort; 

Jetzt fehlt uns nur noch eine entsprechende IntuitText-Struktur, 
und die Ausgabe kann losgehen. 

Ich habe deshalb eine für Sie vorbereitet: 

Struct IntuiText ErsterText = 


C 


1. 0, 

/* FrontPen, BackPen 


JAM2, 

/♦ DrauMode 

*/ 

15, 0, 

/♦ LeftEdge, TopEdge 


NULL, 

/* Font (Standard) 


(UBYTE •) 

"Systemprogranmierung auf dem Amiga!", 


NULL 

>; 

/* NextText 



Diese Definition fügen Sie bitte in unser Standardprogramm 1 
ein. Ich hoffe. Sie erinnern sich noch daran und haben es auch 
sorgfältig abgetippt und abgespeichert. 

Denken Sie daran, daß dieser Definitionstyp vor der main()- 
Funktion stehen sollte. 

Im Hauptprogramm kann dann, nachdem über Open_All() alles 
gelaufen ist, mit der vorher erläuterten Anweisung der RastPort 
des Windows bestimmt werden. 

Nun haben wir fast alle Parameter beisammen, mit denen wir 
PrintITextO aufrufen können. Es fehlen nur noch die Koordi¬ 
natenangaben. 

Jetzt werden Sie sich wundern, wofür wir denn diese benötigen, 
aber schauen Sie sich dazu einmal die folgende Grafik an: 
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PrintlTextOOffset-Oeno 
e 50 100 


PrintlTextO-Test 


50 


100 


Offset zun MindoN aus der Funktion (501, 50L) 
j Gu-ten Tag^ dies ist ein Test 

Relative Position aus der Struktur (20, 20) 


ja 


Abbildung 33: PrintIText()-Offsets 


Beim Aufruf der PrintIText()-Funktion wird entsprechend zum 
RastPort der Punkt bestimmt, auf den sich alle weiteren Anga¬ 
ben in den Strukturen beziehen werden. Dieser Punkt wird 
praktisch zum "Nullpunkt". Die Positionsangabe in der Intui- 
Text-Struktur ist dann relativ dazu zu sehen. 

Fügen Sie zum Abschluß folgende Zeile in das Programm ein: 

PrintIText(MeinesWifxiowsRastPort, ErsterText, 10L, 20L); 

Hinweis: Denken Sie daran, daß die Offsets von PrintITextO 

als LONG-Werte angegeben werden, sonst könnte 
der Aztec-Compiler Schwierigkeiten machen. 

Für alle Interessierten als "Bonbon" das Format der PrintlText- 
Funktion: 

PrintlTextCRastPort, IText, LeftOffset, TopOffset); 

-216 AO AI DO Dl 

Um das Ganze noch abzurunden, biete ich Ihnen zuletzt noch 
eine verkettete (gelinkte) IntuiText-Struktur, die Sie natürlich 
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mit der gleichen Zeile wie oben aufrufen können. Das System 
kümmert sich von alleine darum, ob es mehrere Texte sein 
könnten, und gibt sie alle aus. Es ist darauf zu achten, daß im¬ 
mer der Text zuerst definiert wird, der als letzter in der Liste 
steht, denn sonst erkennt der Compiler die Pointer nicht als de¬ 
finiert! 

struct IntuiText VierterText = 


i 


1, 0. 

/* FrontPen, BackPen 


JAM2, 

/* DrawMode 

*/ 

15, 30. 

/* LeftEdge, TopEdge 

*/ 

NULL, 

/* Font (Standard) 


(UBYTE *) "Dieser Text dient als Beispiel", 


NULL 

>; 

/* NextText 

*/ 

struct IntuiText 

r 

DritterText = 


0. 1, 

/* FrontPen, BackPen 


JAM2, 

/* DrawMode 


15. 20. 

/* LeftEdge, TopEdge 


NULL, 

/* Font (Standard) 


(UBYTE *) "für die Verkettung", 


ÄVierter Text 
>; 

/* NextText 

*/ 

struct IntuiText 

r 

ZweiterText = 


2, 0, 

/* FrontPen, BackPen 

*/ 

JAM2, 

/* DrawMode 

*/ 

15, 10. 

/* LeftEdge, TopEdge 


NULL, 

/♦ Font (Standard) 

*/ 

(UBYTE *) "mehrere Text", 


ÄDritter Text 
>; 

/* NextText 

*/ 

struct IntuiText 

r 

ErsterText = 


3. 0. 

/* FrontPen, BackPen 


JAM2, 

/* DrawMode 

*/ 

15, 0, 

/* LeftEdge, TopEdge 

*/ 

NULL, 

/* Font (Standard) 

*/ 

(UBYTE *) "Über IntuiText.", 


ÄZweiter Text 

/* NextText 

*/ 


>; 
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Die IntuiText-Struktur 
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UBYTE: 
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UBYTE: 
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■ 
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SHORT: 



SHORT: 



SHORT: 
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SHORT: 
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TopEdge 
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H 
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■ 
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1 
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struct IntuiText 



Rnr«i;inf?yn 

■ 


^NextText 
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Abbildung 3.4: IntuiText-Unking 


3.3.2 Linienausgabe und was man damit anfängt 

Als zweites Element unterstützt Intuition die Linienausgabe. Die 
Wichtigkeit dieser Linien wird Ihnen vielleicht bewußt, wenn Sie 
sich z.B. die Workbench-Requester ansehen. Jedes der beiden 
Klickfelder, Gadgets, ist mit einem Doppelkasten umrahmt. 
Aber auch die Schieberegler in den Inhaltsverzeichnisfenstern 
sind mit einem Kasten umrahmt, der auf diese Linien zurück¬ 
geht. Es gibt noch einige weitere Beispiele, an denen wir uns 
aber nicht aufhalten wollen. 

Zuerst soll es, wie auch bei der IntuiText-Struktur, unser Ziel 
sein, die Parameter der Border-Struktur zu untersuchen und zu 
definieren, damit wir im Anschluß daran einfache Linien zeich¬ 
nen können. Da wir dafür etwas mehr Aufwand betreiben müs¬ 
sen, als bei den Texten nötig war, heißt es, sich genauestens mit 
der Materie zu beschäftigen. 
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3.3.2.1 Farbe, Position und und und 

Genau wie auch bei der IntuiText-Struktur können wir auch bei 
der Border-Struktur die Startposition einstellen, an der die erste 
Linie gezeichnet werden soll. Diese wird, wie Sie ja schon bei 
PrintITextO kennengelernt haben, als Offset zu der beim Funk¬ 
tionsaufruf angegebenen Position betrachtet. 

Auch Front- und BackPen lassen sich einstellen, obwohl mo¬ 
mentan BackPen überhaupt nicht genutzt wird, denn eine Linie 
hat ja gar keinen näher definierten Hintergrund. 

Aus dem gleichen Grund können unter DrawMode nicht mehr 
alle vier Modi benutzt werden. Nur JAMl und IN VERSE VID 
sind sinnvoll, weil sich die anderen beiden ja auf die zweite 
Farbe beziehen, die nicht benutzt wird. 

Bevor wir nun zu den neuen Einstellungen kommen, betrachten 
wir zuerst die Border-Struktur: 


3.3.2.2 Die Border-Struktur 


struct Border 
{ 

0x00 00 SHORT LeftEdge 
0x02 02 SHORT TopEdge; 

0x04 04 UBYTE FrontPen 
0x05 05 UBYTE BackPen; 

0x06 06 UBYTE DrauMode; 

0x07 07 BYTE Count; 

0x08 08 SHORT *XY; 

OxOC 12 struct Border *NextBorder; 
0x10 16 

>; 


Im Gegensatz zur IntuiText-Struktur läßt sich bei den Linien 
kein Zeichensatz aussuchen. Dafür benötigen wir einen anderen 
Wert, und zwar eine Angabe, wie viele Eckpunkte unser Linien¬ 
gebilde haben soll. 

Dementsprechend muß der Zeiger nicht auf einen String, son¬ 
dern auf eine Tabelle mit lauter Koordinatenpaaren zeigen. 
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Wie viele es sind, wird durch Count angegeben. 

Wie auch bei den Texten können mehrere Border-Strukturen 
untereinander verknüpft werden, um z.B. die Farbe zu wechseln. 

Es ergibt sich jetzt das neue Problem, daß wir uns noch genauer 
mit der Koordinatentabelle beschäftigen müssen: 


3.3.2.3 Koordinatentabelle zum Linienzeichnen 

Wie viele Koordinaten unsere Tabelle enthalten soll, wird in der 
Struktur über die Variable Count festgelegt. Wir müssen lediglich 
einen Zeiger auf das erste Element übergeben. 

Eine Koordinatentabelle besteht aus lauter SHORT-Wertepaaren, 
jeweils einen für die X-Position und einen für die Y-Position. 
Die Angaben werden als Offsets zu LeftEdge und TopEdge ge¬ 
sehen, die Sie in der Border-Struktur initialisiert haben. 


DraHBorder 0-Offset-Deno 
e 58 188 158 288 


OraMBorderO-Test 


501 


100 


Offset zun UindoH aus der Funktion (50Li SOL) 
. (100, 60) (230, SO) 

1 i ' 


(230, 90) 

Relative Position aus der Struktur (50, 10) 


ja 


Abbildung 3.5: DrawBorder()-Ojfsets 
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Um die Sache noch komplizierter zu machen, kann ich noch ne¬ 
benbei erwähnen, daß diese Koodinaten natürlich auch nur 
einen Offset zu denen des DrawBorder()-Kommandos darstellen. 

Eine Koordinatentabelle könnte z.B. folgendes Aussehen haben; 

SHORT TestUerteC] = 
t 

0 . 0 . 

50, 0. 

50. 12. 

0 . 12 . 

0 , 0 

>; 

Damit haben wir einen rechteckigen Kasten beschrieben, der die 
Breite von 50 Pixeln und die Höhe von 12 Pixeln hat. Achten 
Sie darauf, daß wir für einen Kasten mit vier Ecken fünf Werte 
brauchen: den Startwert und vier Zielwerte für die Linien. 


3.3.2.4 DrawBorder-Funktion mit Anwendungsbeispielen 

Abschließend zur Bestandsaufnahme gehört es natürlich auch, 
endlich mit der Funktion, die uns Intuition zur Verfügung stellt, 
zu arbeiten. Dazu brauchen wir zuerst einmal eine vollständig 
mit Werten besetzte Border-Struktur und eine Koordinatenta¬ 
belle: 


struct Border TestBorder = 
i 

50, 20, 

2 . 0 . 

JAM1, 

5. 

Testwerte, 

NULL 

>; 

Nehmen wir als Koordinaten die schon oben abgedruckte Ta¬ 
belle. Zusätzlich brauchen wir aber noch den RastPort (ich hoffe 
Sie, erinnern sich daran noch von der PrintIText()-Funktion) 
und die Offsets für die Funktion: 
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struct RastPort *MeinesWindowsRastPort; 

MeinesWindowsRastPort = MeinWindow->RPort; 
DrawBorder(MeinesWindowsRastPort, TestBorder, 10L, 10L); 

Bauen Sie jetzt die Border-Struktur, die Koordinatentabelle, den 
RastPort und den Funktionsaufruf in das Standardprogramm 1 
ein. Nach dem Starten sollte ein kleiner Kasten im Fenster er¬ 
scheinen. 


Als zusätzliches Info hier noch das Format der neuen Funktion: 


DrawBorder(RastPort, Border, LeftOffset, RightOffset); 
•108 AO A1 DO D1 


Zuletzt auch noch ein Beispiel für die Verkettung mehrerer Bor- 
der-Strukturen. So wurden z.B. die mehrfarbigen Kästen der 
System-Requester realisiert. 

SHORT UeiBewertet] = 

< 

0 . 0 , 

50, 0. 

50.12. 

0 . 12 . 

0 . 0 

>; 

SHORT RoteWertet] = 

{ 

0 . 0 , 

54, 0. 

54.16. 

0.16. 

0 , 0 

>; 

struct Border UeiBerRand = 

{ 

20 , 20 , 

1 , 0 , 

JAM1, 

5, 

WeiBewerte, 

NULL 

>; 


struct Border RoterRand = 
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18. 18. 

2 . 0 . 

JAN1. 

5. 

RoteWerte, 

WeißerRand 

>; 


DrawBorderCMeinesUindousRastPort, RoterRand, 10L, 10L); 


Die Border-Struktur 


, SHORT! 

^ LeftEdge 



SHORT! 

LeftEdge 


r4 

SHORT! 

LeftEdge 

SHORT: 



SHORT! 



SHORT! 

TopEdge 



TopEdge 



TopEdge 

UBYTE! 



UBYTE! 



UBYTE! 

FrontPen 



FrontPen 



FrontPen 

UBYTE! 



UBYTE! 



UBYTE! 

BackPen 



BackPen 



BackPen 

UBTYE! 



UBTYE! 



UBTYE! 

OraNHode 



DraHNode 



DranHode 

BYTE! 



BYTE! 



BYTE! 

Count 



Count 



Count 

SHORT! 



SHORT! 



SHORT! 

»XY 



*XY 



m 

struct Borden! 



struct Borden! 



struct Borden! 

^^NextBorder 


#NextBorder 


»NextBorder 


Abbildung 3.6: Border-Linfäng 


3.3.3 Grafikausgabe, jetzt wird’s interessant 

Beschäftigen wir uns nun mit der wichtigsten Ausgabefunktion 
Intuitions! Ich meine damit die Grafiken, die Sie eigentlich 
überall wiederfinden. Sehen Sie sich die Workbench mit ihren 
Icons an! Jedes Icon ist eine kleine Grafik, die wir auch bald 
programmieren können. Auch jedes System-Gadget ist eine 
kleine Grafik. Es ist, wie man sieht, nicht weit hergeholt, wenn 
man sagt, daß Grafiken in der Programmierung eine wichtige 
Rolle spielen. 

Der langen Vorrede ist jetzt ein Ende, wir beginnen wieder mit 
den allgemeinen Einstellungen. 
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3.3.3.1 Größe, Position, Farben und vieles mehr 

Genau wie die Texte und Linien hat natürlich jede Grafik eine 
bestimmte Position im Window, die, wie Sie ja schon wissen, 
immer als Offset zu den Koordinaten des Funktionsaufrufes an¬ 
gesehen wird. 

Zu der Positionsangabe kommen noch zwei Werte, die die Größe 
der Grafik bestimmen. Jede Grafik wird als eine rechteckige 
Fläche gesehen, von der wir die Breite und die Höhe angeben 
müssen. 

Eine Neuigkeit finden wir hier aber auch. Es ist Ihnen sicherlich 
bekannt, daß jede Grafik des Amiga immer in mehrere BitPla- 
nes zerlegt wird. Wenn Sie doch nicht so ganz sicher sind, 
möchte ich Sie auf ein weiteres DATA BECKER Buch verwei¬ 
sen. Im Supergrafik-Buch werden alle Grafikmöglichkeiten des 
Amiga ausführlich mit vielen Beispielprogrammen beschrieben - 
hier bleibt leider nicht genug Zeit. Wir müssen zu unserer Gra¬ 
fik nun angeben, aus wie vielen BitPlanes sie besteht, damit sie 
entsprechend verwaltet werden kann. 


3.3.3.2 Die Image-Struktur 


struct Image 

r 

0x00 

00 

SHORT LeftEdge; 

0x02 

02 

SHORT TopEdge; 

0x04 

04 

SHORT Uidth; 

0x06 

06 

SHORT Height; 

0x08 

08 

SHORT Depth; 

OxOA 

10 

USHORT ^ImageData; 

OxOE 

14 

UBYTE PlanePick 

OxOF 

15 

UBYTE PlaneOnOff; 

0x10 

16 

struct Image *NextIinage; 

0x14 

20 



>; 


Die ersten fünf Werte sind oben ja gerade erklärt worden. Sehen 
wir uns deshalb die restlichen vier an! 


Der Pointer ImageData zeigt auf ein oder mehrere Datenfelder, 
die die Grafikdaten enthalten. 
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Mit dem letzten Pointer können wir - wie üblich - mehrere 
Image-Strukturen verbinden. So kann man ganz leicht komplexe 
Grafiken gestalten. 

Die DrawImageO-Funktion von Intuition wird bei ihrem Aufruf 
die Grafikdaten in die BitPlanes unseres Windows oder unseres 
Screen schreiben. Mit dem. Flag PlanePick teilen wir der Funk¬ 
tion mit, welche Planes unserer Grafik auch in die des Windows 
übertragen werden sollen. Jedes Bit steht für eine Plane: 


PlanePick-Wert (binär) Benutzte Planes 


00000000 

Keine 

00000001 

Plane 0 

00000010 

Plane 1 

00000100 

Plane 2 


usw. 

00000011 

Plane 0 und 1 

00000101 

Plane 0 und 2 

00000111 

Plane 0, 1 und 2 


usw. 


Tabelle 3,9: PlanePicky PlaneOnOff 


Mit der Tabelle sollte es für Sie ganz einfach sein, zu bestim¬ 
men, welche BitPlanes der Grafik in das Window übertragen 
werden sollen. Wofür wurde diese Methode gewählt? Über sie 
kann man als Programmierer bestimmte BitPlanes seiner Grafik 
ausschalten. Dies wird oft dazu benutzt, eine Grafik in verschie¬ 
denen Farben auszugeben. Versuchen Sie es ruhig einmal. 

Das andere Flag PlaneOnOff wurde eingeführt, um die nicht 
benutzten BitPlanes ebenfalls zu verwenden. Über die gleichen 
Werte, wie sie in der obigen Tabelle stehen, können Sie ganz 
einfach die BitPlanes angeben, die mit lern gefüllt werden sol¬ 
len. So kann eine Grafik leicht mit Farbe hinterlegt werden. 

Sehen wir uns nun als letztes den Aufbau der Grafikdaten an: 
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3.3.3.3 Die Grafikdaten in der image-Struktur 

Jede Grafik sollte man sich zur Entwicklung auf Millimeterpa¬ 
pier zeichnen. Jedes Kästchen gilt dann als ein Pixel. Diese Ar¬ 
beit müssen Sie für alle BitPlanes machen. Danach erfolgt das 
Ausrechnen der Werte für unsere Daten. 

Gehen Sie dafür wie folgt vor: Zuerst unterteilen Sie das 
Rechteck in Spalten ä vier Pixel. Diese sehen Sie als eine Binär- 
Zahl an, wobei jeder gesetzte Punkt eine 1 bedeutet, und rech¬ 
nen den Wert aus. Das machen Sie eine Zeile lang für jede 
Spalte und notieren sich von links nach rechts die hexadezimalen 
Ziffern. Danach gehen Sie in der nächsten Zeile genauso vor. 

Als kleine Hilfe habe ich Ihnen dafür ein Gitter vorbereitet: 


Für den eigenen Gebrauch ! 



1. BitPlane 2. BitPlane 


Bx 

, Bx 

Bx 


Bx 

Bx 

, Bx 

Bx 


Bx 

Bx 

, Bx 

Bx 

; 

Bx 

Bx 

, Bx 

Bx 


Bx 

Bx 

, Bx 

Bx 

j 

Bx 

Bx 

, Bx 

Bx 

} 

Bx 

Bx 

, Bx 

Bx 

f 

Bx 

Bx 

, Bx 

Bx 

> 

Bx 

Bx 

. Ox 

Bx 


Bx 

Bx 

1 ex 

Bx 


Bx 

Bx 

, Bx 

Bx 

p 

Bx 

Bx 

, Bx 

Bx 


Bx 

Bx 

, Bx 

Bx 

} 

Bx 

Bx 

, Bx 

Bx 

} 

Bx 

Bx 

, Bx 

Bx 

} 

Bx 

Bx 

, Bx 

Bx 

ß 

Bx 


Abbildung 3.7: Gitterßr eigene Grafiken 


Eine andere Möglichkeit gibt es, wenn Sie binäre Zahlen ver¬ 
wenden. Dann können Sie diese einfach aus der Grafik über¬ 
nehmen, indem Sie jeden gesetzten Punkt durch eine 1 und je¬ 
den ungesetzten Punkt durch eine 0 darstellen. Es ist nur die 
Frage, ob Ihr Compiler binäre Zahlen verarbeitet. 
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Besteht Ihre Grafik aus mehreren BitPlanes, dann müssen zuerst 
die Daten für die erste BitPlane, anschließend die für die zweite 
BitPlane usw. in der Werteliste folgen. 


3.3.3.4 Die Drawimage-Funktion und ihre Anwendung 

Nach so viel Theorie gibt es nun endlich mehr Beispiele! Stürzen 
wir uns also ins Geschehen und betrachten die erste Image- 
Struktur: 


struct Image Beispiel = 
i 

20 . 10 , 

16. 16. 

2 , 

&Beispiel0aten[0], 

3, 0, 

NULL 

>; 

Dafür brauchen wir natürlich auch die dazugehörige Zeichnung, 
die ich schon vorbereitet habe: 


Inage-Data Beispiel 



_ 1. BitPlane 

2. BitPlane 

_ exB7F8; BxOBBO 

BxBBBB; 

BxBBBB 

. BxB7FB, BxBBBB 

BxBBBB; 

BxBBBB 

_ BxlElE; BxBBBB 
_ BxlElE; BxBBBB 

BxBBBB; 

BxBBBB 

BxBBBB; 

BxBBBB 

_ Bx78BB; BxFEBB 

BxBBBB; 

BxFEBB 

_ Bx788B; BxFSBB 

BxBBBB; 

BxFSBB 

_ 8x78BB; BxBBBB 

BxBBBB; 

BxBBBB 

_ Bx78BB, BxBBBB 

BxBBBB; 

BxBBBB 

_ Bx78BB; BxFSBB 

BxBBBB; 

BxFSBB 

_ Bx78BB; BxFEBB 

BxBBBB; 

BxFEBB 

. BxlElE; BxBBBB 

BxBBBB; 

BxBBBB 

. BxlElE; BxBBBB 

BxBBBB; 

BxBBBB 

. BxB7F8; BxBBBB 

BxBBBB; 

BxBBBB; 

BxBBBB 

. BxB7F8; BxBBBB 

BxBBBB 


Abbildung 3.8: ImageData 
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Das Datenfeld sieht dafür folgendermaßen aus (denken Sie beim 
Einsetzen in das Standardprogramm I daran, daß Sie es vor der 
Image-Struktur definieren): 

USHORT BeispielDatenC] = 


i 


/* erste BitPlane */ 

0x07F8, 

0x0000, 

OxOZFO, 

0x0000, 

OxiEIE, 

0x0000, 

OxiEIE, 

0x0000, 

0x7800, 

OxFEOO, 

0x7800, 

0XF800, 

0x7800, 

0x0000, 

0x7800, 

0x0000, 

0x7800, 

0xF800, 

0x7800, 

OxFEOO, 

OxiEIE, 

0x0000, 

OxiEIE, 

0x0000, 

0x07F8, 

0x0000, 

0x07F8, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

/* zweite BitPlane V 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

OxFEOO, 

0x0000, 

0xF800, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0xF800, 

0x0000, 

OxFEOO, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000, 

0x0000 


>; 


Als letztes müssen wir noch den RastPort des Windows ermitteln 
und die Ausgabefunktion Drawlmage() aufrufen: 

struct RastPort *MeinesWindowsRastPort; 

MeinesUindowsRastPort = Meii1Uinclow->RPort; 
DrawImagetNeinesUindowsRastPort, Beispiel, 10L, 10L); 
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Als zusätzliche Information noch das allgemeine Format: 

DrawIinagetRastPort, Image, LeftOffset, TopOffset); 

-114 AO AI DO Dl 

Bedenken Sie, daß unser Grafik-Chip nur Speicher ansprechen 
kann, der im sog. Chip-Memory liegt. Das ist der Speicherbe¬ 
reich bis 512 KByte. Es gibt nun zwei Möglichkeiten, dafür 
Sorge zu tragen, daß die Grafikdaten in diesen Speicherbereich 
kommen. Die Compiler bieten eine Option, mit der alle Daten in 
den Chip-Memory transferiert werden können. Das ist wohl die 
einfachste Methode. Es läßt sich aber auch im Programm 
durchführen. Dazu müssen Sie sich Speicher im Chip-Memory 
besorgen und die Grafikdaten in diesen kopieren. Erst jetzt kön¬ 
nen Sie die Grafik initialisieren und ausgeben. 


3.3.4 Beispiele für jede Grafikanwendung 

Abschließend zum Grafik-Kapitel im Intuition-Teil möchte ich 
Ihnen ein paar Anwendungen vorstellen, für die Sie sicherlich 
Interesse haben werden. 

Es war nicht schwer zu erkennen, wie einfach die Bestimmung 
der Strukturenwerte ist. Viele Einstellungen machen es möglich, 
auf jeden Wunsch des Programmierers einzugehen. Vielleicht 
liegt gerade dort das Problem. Hat man z.B. sehr viele gleiche 
Texte, so kann es schon ärgerlich werden, wenn man immer 
wieder die IntuiText-Struktur mit den gleichen Werten ausfüllen 
muß. Dafür möchte ich in diesem Kapitel eine selbst program¬ 
mierte Funktion vorstellen, die Abhilfe schafft. 

Zusätzlich finden Sie hier einige kleine Grafiken, Texte und Li¬ 
nien, die wir für die Gadgets im nächsten Kapitel gut gebrau¬ 
chen können. Wir erweitern unseren C-Quelltext-Editor wieder 
um ein kleines Stück. 

Natürlich soll das CLI-Fenster nicht vergessen werden. Ich habe 
dafür ein Gadget vorbereitet, mit dem endlich das lästige Sizen 
auf bestimmte Werte entfällt. 
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Stürzen wir uns nun in das Abenteuer... 


3.3.4.1 Auf einfache Weise vieie Texte definieren 

Es tritt öfter das Problem auf, daß man in seinem Programm mit 
vielen Texten arbeiten muß, die alle einzeln über eine 
IntuiText-Struktur definiert werden müssen. Da wir nicht immer 
eine neue Zeichenfarbe auswählen und uns meistens auch auf 
einen Zeichensatz beschränken, kann man als Programmierer 
gelegentlich ins Schwitzen kommen, wenn man 20 solcher 
Strukturen definieren muß. 

Natürlich gibt es auch dafür eine Lösung, und die sieht folgen¬ 
dermaßen aus: Zuerst definieren wir eine sog. Default-Struktur, 
in der nur alle Parameter eingetragen sind, nicht aber der Zeiger 
auf den String. Hier ein konkretes Beispiel: 

struct TextAttr DefaultFont = 
t 

(STRPTR)"topaz.font", 

TOPAZ EIGHTY, 

FS NORMAL. 

FPF ROMFONT 
>; ■ 

struct IntuiText DefaultText = 


{ 


1. 0, 

/* 

FrontPen, BackPen 

*/ 

JAM2, 

/* 

DrawMode 

*/ 

1. 1. 

/* 

LeftEdge, TopEdge 

*/ 

&DefaultFont, 

/* 

Font 


NULL. 

/* 

Textpointer 


NULL 

>; 

/* 

NextText 



Struktur 3.6: DefaultText 

Gleichzeitig habe ich noch eine TextAttr-Struktur initialisiert, 
damit auch immer der richtige Zeichensatz benutzt wird. 

Für die Texte, die später in diese Struktur eingesetzt werden 
sollen, definieren wir ein Pointerfeld des Typs char, so kommen 
wir an jeden String leicht heran: 



Intuition und C für Fortgeschrittene 


307 


char *TextfeldC] = 

“Erster Testtext“, 

“hier ist der zweite“, 

“und noch einer", 

“hier haben wir schon den letzten und längsten!" 

>; 

Nun fehlt nur noch ein Feld von IntuiText-Strukturen, in das 
wir über ein Unterprogramm die Default-Struktur-Werte eintra¬ 
gen lassen und dann den Pointer ergänzen. 

struct IntuiText AlleTexteC4]; 

Sehen wir uns schließlich das Unterprogramm an, welches die 
eben genannte Arbeit übernimmt: 

Make_Text(Anzahl, Texte, Struktur) 

int Anzahl; 

char ^Texten; 

struct IntuiText StrukturC]; 

i 

int i; 

for (i=0; i<Anzahl; i++) 
i 

Struktur[i] = DefaultText; 

Struktur[i].IText = (UBYTE ♦) Texteli]; 

Struktur Ci].NextText = ÄStrukturCi+1]; 

> 

Struktur[Anzah1-1].NextText = NULL; 

> 


Funktion 3.3: Make Text 


Dokumentation 

Nachdem auch für das Unterprogramm die übergebenen Vari¬ 
ablen deklariert worden sind, beginnt es mit seiner Arbeit in ei¬ 
ner Schleife. Hier wird der als Feld definierten Struktur zuerst 
immer die Default-Struktur zugewiesen. Damit sind die allge¬ 
meinen Werte initialisiert! Danach ergänzen wir den Pointer auf 
den ersten String und verketten die erste IntuitText-Struktur mit 
der zweiten. Die Schleife wird je nach Anzahl mit den nächsten 
Werten durchlaufen. Damit die letzte Struktur nicht auf eine 
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nicht vorhandene zeigt, muß der überflüssig gesetzte Zeiger 
wieder gelöscht werden. 

Wenn Sie die Texte nicht miteinander verketten möchten, so 
können die zwei dafür vorgesehenen Zeilen natürlich entfallen. 
Sie dürfen ebenfalls jederzeit irgendwelche Ergänzungen ma¬ 
chen. Zum Beispiel eine automatische Zeilenberechnung als Ko¬ 
ordinateninitialisierung. 


3.3.4.2 Border-Hilfen, die man immer brauchtl 

ln diesem Abschnitt wollen wir schon etwas Vorarbeit für das 
nächste Kapitel leisten. Dort werden wir uns mit den Gadgets 
beschäftigen. Diese Gadgets benutzen nun auch alle drei Ausga¬ 
beelemente, die Sie hier kennengelernt haben. Wie es ja oft üb¬ 
lich ist, wird ein Kasten zur Begrenzung des Klickfeldes eines 
Gadgets benutzt. Deshalb wollen wir eine Border-Struktur ent¬ 
wickeln, mit der wir später Weiterarbeiten können. 

Außerdem kann man sich wie auch bei Texten einige Arbeit ab¬ 
nehmen lassen. Denken Sie z.B. nur an Textumrandungen, die 
immer unterschiedliche Länge haben. Warum lassen wir das 
nicht einfach von einer Funktion berechnen? 

Nehmen wir als erstes Beispiel die einfach und zweifach umran¬ 
deten Texte. Sie werden z.B. bei BECKERtext und TEXTOMAT 
von DATA BECKER dazu verwendet, zu kennzeichnen, welches 
Gadget auch durch die Return-Taste ersetzt werden kann. 

Hier ist der einfache Rand (er ist für 8 Buchstaben gedacht): 

SHORT einfachWerteC] = 
i 

0 , 0 , 

66 , 0 . 

66 , 10 . 

0 , 10 , 

0 , 0 

>; 


struct Border einfachRand = 
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0 . 0 , 

1 , 0 . 

JAM1, 

5. 

einfachwerte, 

NULL 

>; 


Struktur 3.7: Einfacher Rand 


... und passend dazu der zweite: 

SHORT doppeltUertet] = 

0 . 0 . 

70, 0, 

70, U. 

0,U, 

0 , 0 

>; 

struct Border doppeltRand = 

< 

- 2 , - 2 , 

2 , 0 , 

JAM1, 

5, 

doppeltwerte, 

NULL 

>; 


Struktur 3.8: Doppelter Rand 


... er kann leicht über den Pointer angefügt werden! 


einfachRand.NextBorder = &doppeltRand; 

Als nächstes biete ich eine Lösung für das Problem an, einen 
Rand für einen Text, dessen Länge das Programm erst beim 
Ablauf kennt, zu definieren. 


Als allgemein müssen vor dem Hauptprogramm eine Border- 
Struktur und ein Wertefeld definiert werden. Das sollte etwa so 
aussehen: 
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SHORT »Wertet] = 

0 . 0 . 

999. 0. 

999,10, 

0 , 10 , 

0 , 0 

>; 


struct Border Rand = 
{ 

0 . 0 , 

1 , 0 , 

JAM1, 

5, 

&Uerte[0], 

NULL 

>; 


Struktur 3.9: Allgemeine Border 


Außerdem benötigen wir eine IntuiText-Struktur, in die nur 
noch der Pointer für den Text eingesetzt wird: 

struct IntuiText Text = 


< 


1, 0, 

/* FrontPen, BackPen 


JAM2, 

/* DrawMode 

*/ 

2, 2, 

/* LeftEdge, TopEdge 

*/ 

NULL, 

/* Font (Standard) 

*/ 

NULL, 

/* Textpointer 

♦/ 

NULL 

>; 

/* NextText 



Struktur 3.10: Allgemeiner IntuiText 

Sowohl Text als auch Border werden mit den gleichen Offsets in 
den RastPort geschrieben: 

DrauBorder(RastPort, Rand, 10L, 10L); 

PrintITexttRastPort, Text, 10L, 10L); 

Bevor dies gemacht werden kann, muß noch die Funktion auf¬ 
gerufen werden, die die Border-Werte richtig berechnet. Sie ist 
ganz einfach zu verstehen: 
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BerechneCWerte, Text) 

USHORT *Werte[]; 

struct IntuiText Text; 

C 

int Breite = 0; 

Breite = IntuiTextLenght(Text); 

Werte[3] = Breite+4; 

Werte[5] = Breite+4; 

> 


Funktion 3.4: Textlänge berechnen 

Das einzige Unbekannte ist die IntuiTextLength()-Funktion, die 
uns als Werte die Breite des Textes in Pixeln zurückgibt. Dabei 
berücksichtigt sie auch den Zeichensatz! 

Haben wir den Wert, dann setzen wir ihn einfach in das Feld 
ein. 


3.3.4.3 Symbole sagen mehr als Worte 

Als Ergänzung zum Abschnitt über die Images möchte ich hier 
eine Grafik liefern, die später als Symbol für ein Gadget dienen 
wird. 

Damit soll ein großer Bogen zum Kapitel gespannt werden, in 
dem ich das CLI-Editor-Fenster vorgestellt habe. Im nächsten 
Kapitel möchte ich als erste wirklich nützliche Anwendung das 
Gadget präsentieren, zu dem wir eben dieses Symbol benötigen. 

Die Aufgabe, die beim Anklicken bewältigt werden soll, ist 
denkbar einfach. Für den Anwender ist es immer lästig, wenn er 
das Fenster für viel Text auf maximale Größe ziehen muß. Ge¬ 
nauso umständlich ist es, wenn man es ganz klein machen 
möchte. 
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Da wir dies auch über Window-Funktionen erledigen können, 
lösen wir die Aktion einfach über das angesprochene Gadget 
aus. Dafür brauchen wir ein Symbol. 

Das Symbol soll ein kleines Fenster und ein großes Fenster dar¬ 
stellen. Zwischen diesen beiden Fenstern besteht der Größen¬ 
wandel, der durch die Linie gekennzeichnet wird. 


Inage-Data CLI-Uide 



1. BitPlane 
BxFFBB; BxBBBB 
BxBlBB; BxBBBB 
BX91FF; BxBBBB 
BxBCBl; BxBBBB 
BxFFBl; BxBBBB 
BxlBCl; BxBBBB 
BxiB21; BxBBBB 
BxlBBl; BxBBBB 
BxlBBl; BxBBBB 
BxlFFF; BxBBBB 
BxBBBB; BxBBBB 
BxBBBB; BxBBBB 
BxBBBB; BxBBBB 
BxBBBB; BxBBBB 
BxBBBB; BxBBBB 
BxBBBB; BxBBBB 


Abbildung 3.9: Resize-Gadget 


Es dürfte für Sie wohl kein Problem sein, aus dem Schaubild 
und den Daten eine Image-Struktur mit Grafikdaten aufzubauen. 


3.4 Gadgets, einfacher Informationsaustausch 

Anwenderprogramme benötigen allgemeine Informationen wie 
Text oder Daten, um arbeiten zu können. Außerdem brauchen 
sie Anweisungen, mit deren Hilfe sie in ihrer Ausführung ge¬ 
lenkt werden. In diesem Kapitel klären wir die Frage: "Wie 
übermittle ich dem Programm einfach Informationen und auf 
welche Weise kann ich das tun?" 
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Als versierter Amiga-Besitzer wissen Sie natürlich, daß die 
leichteste Informationsübermittlung über die sog. Gadgets ab¬ 
läuft. Das sind rechteckige Klickfelder in Windows oder auf 
Screens, die beim Anklicken mit der linken Maustaste reagieren. 

Der Amiga kennt aber nicht nur einfache Gadgets, wie das, bei 
dem nur ein Klickimpuls weitergeleitet wird. Es gibt auch Gad¬ 
gets, die man ein- oder ausschalten kann, die man für Textein¬ 
gabe benutzen kann, und solche, die man für Positionsangaben 
verwendet. Alle diese vollkommen verschiedenen Typen sind 
auch noch in Untergruppen unterteilt. Sie haben also die vielfäl¬ 
tigsten Möglichkeiten, Informationen vom Benutzer in das Pro¬ 
gramm zu holen. 

Weil man aber diese Klickfelder nicht erkennen würde, wenn sie 
einfach nur "da wären", unterstützt es Intuition, die rechteckigen 
Felder mit Rändern, Grafiken und Texten "auszuschmücken". 
Deswegen sind die Ausgabetechniken, die ich im vorhergehen¬ 
den Kapitel beschrieben habe, so besonders wichtig. 

Sie haben jetzt einen Vorgeschmack von dem bekommen, was 
alles möglich ist. Auch das klare Konzept von Intuition läßt im¬ 
mer mehr erkennen, wie einfach und doch komplex es aufgebaut 
ist: Einfache Screens dienen als elementare Einstellung des Gra¬ 
fikmodus. Windows stellen eine einfache Ein- und Ausgabeein¬ 
heit dar. Über die Ausgabefunktionen lassen sich mit wenigen 
Mitteln durchdachte Strukturen ausgeben. Jetzt werden alle diese 
Mittel kombiniert, damit der Programmierer für seine Anwen¬ 
dung wie aus einem Baukastensystem alles Nötige "basteln" kann. 


3.4.1 Verschiedene Gadgets, verschiedene Anwendungen 

Intuition bietet ihnen zwei große Gadget-Kategorien zur Arbeit 
an. Da sind zuerst die System-Gadgets. Sie werden von Intuition 
angeboten und sind in ihrem Aussehen und in ihrer Wirkung 
festgelegt. Dazu lesen Sie mehr im Window-Kapitel. 

Die zweite Gadget-Gruppe ist einzig für den Programmierer ge¬ 
dacht und unterstützt das eigene Anfertigen. Sie können aus drei 
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verschiedenen Gadget-Typen wählen, die vollkommen unter¬ 
schiedliche Eigenschaften haben. 


Boolean-Gadgets 

Für ganz einfache Informationen, die nur aus einem Wahrheits¬ 
wert bestehen (Ja oder Nein), sind Boolean-Gadgets vorgesehen. 
Sie bieten zwei Modi: 

Der erste Modus heißt "hit select" und bedeutet, daß Intuition 
eine Information sendet, wenn das Gadget über die linke 
Maustaste, sie wird im folgenden Action-Taste genannt, an¬ 
geklickt wird. Dabei verändert sich für die Zeit, in der sich der 
Maus-Cursor im Klickfeld befindet, das Aussehen des Gadgets. 
Bewegt man die Maus wieder weg oder läßt man den Button los, 
ist das Aussehen wieder wie vorher. Über diesen Modus können 
Sie ganz einfach bestimmte Aktionen auslösen. 

Mit dem zweiten Modus, "toggle select", schalten Sie mit dem 
ersten Anklicken das Gadget an. Es verändert dann sein Ausse¬ 
hen so, als wäre es ständig angeklickt. Mit einem zweiten An¬ 
klicken wird das Gadget wieder in den Urzustand gebracht. 
Diese Methode eignet sich besonders gut für das Ein- und Aus¬ 
schalten von irgendwelchen Funktionen. 


Proportional-Gadgets 

Möchten Sie Bereiche oder Positionen darstellen, dann ist dieser 
Gadget-Typ geeignet. Mit ihm können Sie eindimensional oder 
zweidimensional bestimmte Proportionen ausgeben und vom Be¬ 
nutzer Ihres Programms verändern lassen. 

Dieses Gadget besteht aus einem rechteckigen Kasten, in dem 
sich ein beliebiges Objekt befindet. Ich halte den Begriff hier 
absichtlich allgemein, weil Sie dafür jede beliebige Grafik defi¬ 
nieren können. Das Objekt stellt z.B. bei Preferences die Kante 
des Workbench-Screens dar, die Sie über ein Proportional-Gad- 
get einstellen können. In diesem Fall ist es sogar ein zweidimen¬ 
sionales. Ein Beispiel für eindimensionale Proportional-Gadgets 
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sind die Schieber der Inhaltsverzeichnis-Windows. Der Balken, 
unser "Objekt", stellt die Größe des Ausschnitts dar und kann im 
gesamten Bereich hin- und hergeschoben werden. 

Für jedes Proportional-Gadget können Sie die Größe des 
Schiebekastens (Container), das verwendete Objekt (knob) und 
die Größe des Objektes einstellen. 


String-Gadget 

Um einfache Texteingabe realisieren zu können, ist dieser Typ 
implementiert worden. Sie haben wie beim Proportional-Gadget 
einen "Container", in dem der Text einzeilig eingegeben werden 
kann. Dabei spielt die Länge überhaupt keine Rolle: Intuition 
scrollt den Text, wenn nötig. 

Zusätzlich werden noch einige Funktionen wie UNIX) unter¬ 
stützt, so daß die Eingabe komfortabel getätigt werden kann. 

Jetzt kennen Sie alle Gadget-Typen mit ihren grundsätzlichen 
Eigenschaften. Sie sollten sich die Einzelheiten genau ansehen, 
damit Sie, nach Auswahl eines Typs, diesen auch wirklich gut 
programmieren können. 


3.4.1.1 Das Boolean-Gadget 

Einer der am meisten verwendeten Gadget-Typen ist das Boo¬ 
lean-Gadget. Wir finden es schon bei den System-Gadgets drei¬ 
mal wieder: Im Close-Gadget und in den beiden Depth-Arran- 
gement-Gadgets. 

Boolean-Gadgets stellen den Grundtyp aller Gadgets dar, deshalb 
behandeln wir diesen auch besonders ausführlich. 

Jedes Gadget kann in seiner Position, Höhe und Breite festgelegt 
werden - eine selbstverständliche Einstellung. Sehen Sie sich 
doch die Struktur an, bevor wir auf die anderen Werte eingehen: 
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struct Gadget 

r 

0x00 

00 

struct Gadget *NextGadget; 

0x04 

04 

SHORT LeftEdge; 

0x06 

06 

SHORT TopEdge; 

0x08 

08 

SHORT Width; 

OxOA 

10 

SHORT Height; 

OxOC 

12 

USHORT Flags; 

OxOE 

14 

USHORT Activation; 

0x10 

16 

USHORT GadgetType; 

0x12 

18 

APTR GadgetRender; 

0x16 

22 

APTR SelectRender; 

OxIA 

26 

struct IntuiText *GadgetText 

0x1 E 

30 

LONG HutualExclude; 

0x22 

34 

APTR SpecialInfo; 

0x26 

38 

USHORT GadgetID; 

0x28 

40 

APTR UserData; 

0x2C 

44 



>; 


Genau wie bei allen anderen bisher behandelten Intuition- 
Strukturen, können auch Gadgets gelinkt werden. Dafür steht 
der erste Pointer. Nach den Werten für linke und rechte Ecke, 
Höhe und Breite finden wir ein Flag, das mehrere Aufgaben 
erfüllt. 


In Flags finden wir zuerst einmal die Einstellungen zur Grafik 
des Gadgets. Sie können angeben, auf welche Weise das Gadget- 
Aussehen verändert werden soll, wenn es angeklickt wird. Dafür 
stehen Ihnen vier GADGHIGHBITS zur Verfügung: 

GADGHCOMP 

Alle Punkte im Klickbereich werden komplementiert dargestellt. 
GADGHBOX 

Um den Klickbereich wird ein Kasten gezeichnet. 

GADHIMAGE 

Es wird ein anderes Image oder eine andere Border dargestellt. 
GADGHNONE 

Keine Veränderung tritt ein. Weiterhin beinhaltet das Flag Posi¬ 
tionsangaben zum Gadget: 
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GRELBOTTOM 

Wenn Sie dieses Flag setzen, beschreibt die TopEdge-Variable 
der Struktur einen Offset relativ zum Fuß des Fensters. Ist das 
Flag nicht gesetzt, dann ist TopEdge eine relative Angabe zum 
oberen Rand des Fensters. 

GRELRIGHT 

Wenn Sie dieses Flag setzen, beschreibt die LeftEdge-Variable 
der Struktur einen Offset relativ zum rechten Rand des Fensters. 
Ist das Flag gelöscht, dann ist LeftEdge relativ zum linken Rand 
zu sehen. 

Auch die Größe des Gadgets können Sie in Abhängigkeit zum 
Fenster setzen: 

GRELWIDTH 

Wenn Sie dieses Flag setzen, wird der Wert der Width-Variable 
von der Fensterbreite abgezogen, und das Ergebnis stellt dann 
die wirkliche Breite des Gadgets dar. Setzen Sie das Flag nicht, 
dann steht in Width ein absoluter Wert! 

GRELHEIGHT 

Wenn Sie dieses Flag setzen, wird der Wert der //e/^A/-Variablen 
von der Fensterhöhe abgezogen, und das Ergebnis stellt die 
wirkliche Höhe des Gadgets dar. Löschen Sie die Flags, wenn 
der Wert absolut gesehen werden soll. 

Für den Status des Gadgets sind drei Flags vorgesehen: 

GADGIMAGE 

Wenn Sie dieses Flag setzen, wird anstelle einer Border ein 
Image in der Variablen GadgetRender vermutet. Die Bedeutung 
erstreckt sich auch auf die Variable SelectRenderl 

GADGDISABLED 

Dieses Flag ist gesetzt (es kann nur zu Anfang gesetzt und später 
nur abgefragt werden), wenn das Gadget nicht anwählbar ist. 
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SELECTED 

Dieses Flag ist gesetzt - es kann nur zu Anfang gesetzt und 
später nur abgefragt werden wenn das Gadget selected wurde. 

Zum Schluß noch einmal alle Flags mit ihren Hex-Werten: 


Flags 

Hex-Wert 

GADGHIGHBITS 

0x00031 

GADGHCOMP 

OxOOOOL 

GADGHIMAGE 

0x0002L 

GADGHBOX 

0x00011 

GADGHNONE 

0x0003L 

GRELBOTTOM 

OxOOOSL 

GRELRIGHT 

0x001OL 

GRELUIDTH 

0x0020L 

GRELHEIGHT 

0X0040L 

GADGIMAGE 

0x0004L 

SELECTED 

OxOOSOL 

GAOGOISABLED 

0x01OOL 

Tabelle 3.10: 

Gadget-Flags 


Kommen wir jetzt zum nächsten Wert unserer Gadget-Struktur. 
Es ist wiederum ein Flag. Es enthält diesmal Informationen dar¬ 
über, wie das Gadget aktiviert werden soll und ob es sich im 
Window-Rand befinden soll: 

Betrachten wir zuerst die Flags, die sich mit dem Aktivierungs¬ 
status beschäftigen: 

TOGGLESELECT 

Wie oben schon angesprochen wurde, gibt es einen besonderen 
Typ des Boolean-Gadgets. Dieser wird durch dieses Flag be¬ 
stimmt. Danach wird das Gadget wie ein Schalter behandelt: 
Beim ersten Anklicken wird es eingeschaltet und bleibt solange 
in diesem Status, bis es wieder angeklickt wird. 
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GADGIMMEDIATE 

Bei einfachen Boolean-Gadgets kann der Programmierer noch 
zwischen zwei Select-Modi wählen: Einmal angewählt erhält das 
Programm sofort eine Nachricht. Das geschieht, wenn dieses 
Flag gesetzt ist. 

RELVERIFY 

Wurde dieses Flag gesetzt, wartet Intuition mit der Nachricht, 
bis der Benutzer auch den Action-Button über dem Klickbereich 
losläßt. Man gesteht dem Anwender damit noch eine Schreckse¬ 
kunde zu. 

Für die Position des Gadgets gibt es noch mehr Variationen. 

Diese beziehen sich aber nicht auf die Lage, sondern mehr auf 
die Verwaltung. Sie wissen ja, daß über den Window-Typ 
GIMMEZEROZERO der Window-Rand extra verwaltet wird, 
damit dessen Grafik nicht beschädigt werden kann. 

Unsere eigenen Gadgets können wir auch darin unterbringen! 
Setzen Sie dafür eins der folgenden Flags. 

Beachten Sie aber, daß dadurch die Breite des Randes beeinflußt 
wird: 

RIGTHBORDER 

Das Gadget wird im rechten Window-Rand untergebracht. 
LEFTBORDER 

Das Gadget wird im linken Window-Rand untergebracht. 
TOPBORDER 

Das Gadget wird im oberen Window-Rand untergebracht. 
BOTTOMBORDER 

Das Gadget wird im unteren Window-Rand untergebracht. 
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Breite der UindoM-Ränder 

I 


Oberer Rand 

ln 


Linker 

Rand 


u 



Unterer Rand 


Rechter Rand 


Abbildung 3.10: Gadgets im Window-Rand 


Die folgende Tabelle faßt alle Activation-Flags zusammen: 


Activation-Flag 

Hex-Wert 

Bemerkung 

TOGGLESELECT 

0x01001 

Schalter-Gadget 

RELVERIFY 

0x0001L 

V erge wisserung 

GADGIMMEDIATE 

0x0002L 

Sofort 

RIGHTBORDER 

0x001OL 

Position in GZZ-Border. 

LEFTBORDER 

0x0020L 


TOPBORDER 

0X0040L 


BOTTONBORDER 

OxOOSOL 


STRINGCENTER 

0X0200L 

Später für String-Gadgets. 

STRINGRIGHT 

OxOAOOL 


LONGINT 

OxOSOOL 

Für Integer-Gadgets. 

ALTKEYMAP 

OxIOOOL 

Eigene Tastaturtabelle. 
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Activation-Flag 

Hex-Wert 

Bemerkung 

BOOLEXTEND 

0x20001 


ENDGADGET 

0x00041 

Für Requester. 

FOLLOWMOUSE 

0x00081 

Für IDCMP. 

Tabelle 3.11: 

Activation-Flags 



Kehren wir wieder zurück zu der Gadget-Struktur, die es immer 
noch zu untersuchen gilt! Wir kommen jetzt zum letzten Flag- 
Wert, der etwas über den Typ des Gadgets aussagt. GadgetType 
enthält aber noch weitere Informationen: 

BOOLGADGET 

Ein Boolean-Gadget, das wir auch in diesem Kapitel program¬ 
mieren werden. 

PROPGADGET 

Ein Proportional-Gadget, zu dem Sie später noch mehr erfahren 
werden. 

STRGADGET 

Ein String-Gadget, mit dem Sie einfache Texteingabe realisieren 
können. Für ein Integer-Gadget setzen Sie bitte zusätzlich noch 
das LONGINT-Flag in der Flags-Variablen der Struktur. 

Mit diesen drei Flags bestimmen Sie den Gadget-Typ. Über zwei 
weitere Flags, die vom System gesetzt werden, erfährt man etwas 
darüber, vom wen das Gadget stammt und wo es liegt. 

SCRGADGET sagt, daß das Gadget zu einem Screen gehört, und 
SYSGADGET identifiziert die System-Gadgets in einer Liste. 

Soll das Gadget in einem GZZ-Window in dessen Rand unterge¬ 
bracht werden, so ist zusätzlich zum Bestimmungs-Flag des 
Randes auch noch GZZGADGET zu setzen! 
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GadgetType 

Hex-Wert 

Bedeutung 

BOOLGADGET 

0x00011 


GADGET0002 

0x00021 

Unbenutzt 

PROPGADGET 

0x00031 


STRGADGET 

0x0004L 


SYSGADGET 

OxBOOOL 

System- G adget 

SCRGADGET 

0x4000L 

Screen-Gadget 

GZZGADGET 

0x20001 

GIMMEZEROZERO- 



W indow - G adget 

REQGADGET 

OxIOOOL 

Requester- G adget 


Tabelle 3.12 Gadget-Typen 


Endlich kommen wir, nach so vielen Flags und Einstellungen, zu 
den sichtbaren Merkmalen der Gadgets. Wir beschäftigen uns 
nun mit der Grafik, die wir zur Kenntlichmachung mit dem 
Gadget verknüpfen werden. Über die Höhe, Breite und Position 
haben wir nur die Lage und Ausdehnung des Klickbereiches 
definiert. Nun ist es an der Zeit, diesen auch für den Benutzer 
unseres Programms "sichtbar" zu machen. Dafür verwenden wir 
eine Border- oder eine Image-Struktur. Ein Zeiger auf eine der 
beiden Strukturen-Typen wird in der Variablen GadgetRender 
untergebracht. Diese Grafik wird dann beim Darstellen des Gad¬ 
gets ausgegeben. 

Haben wir zusätzlich noch festgelegt, daß beim Anklicken ein 
anderes Aussehen erwünscht ist, dann muß in der Variablen Se- 
lectRender ein weiterer Zeiger auf eine Border- oder Image- 
Struktur stehen. 

Allerdings können wir nicht einfach einmal eine Border-Struktur 
und dann wieder eine Image-Struktur verwenden. Wie Sie oben 
sehen konnten, gibt es für jeden Modus natürlich ein Flag. Das 
heißt, daß für eine Image-Struktur das Flag GADGIMAGE ge¬ 
setzt werden nauß und für eine Border-Struktur kein Flag. 

Für SelectRender legen wir uns mit GADGIMAGE gleich mit 
fest, jedoch ist es nicht gesagt, daß dort auch ein Pointer stehen 
muß. Nur wenn auch das Flag GADGHIMAGE gesetzt ist, sucht 
Intuition auch dort nach einem Struktur-Pointer. 
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Für weitere Gestaltungen des Gadgets bietet Intuition einen Zei¬ 
ger auf eine IntuiText-Struktur an, über den wir gleichzeitig 
noch einen Text unterbringen können. Dieser Text hat aber 
nichts mit dem Anwählen des Gadgets zu tun! 

Die letzten vier Werte der Struktur sind für komplexere Anwen¬ 
dungen gedacht. Damit wir aber endlich zu praktischen Anwen¬ 
dungen kommen können, möchte ich sie zuerst außer acht lassen. 
Später werde ich auf sie zurückkommen. 


Das erste Gadget 

Wenden wir uns nun der Programmierung zu. Ich habe die fol¬ 
gende Gadget-Struktur für das erste Beispiel vorbereitet: 

struct Gadget BoolGadget = 
i 


NULL, 

/* NextGadget 

*/ 

10, 40, 

/* LeftEdge, TopEdge 

*/ 

60, 20, 

/* Uidth, Height 

*/ 

GAOGHBOX, 

Flags 

*/ 

RELVERIFY, 

/* Activation 

*/ 

BOOLGADGET, 

/* Gadget Type 


(APTR)&GadgetBorder, 

/* GadgetRender 

*/ 

NULL, 

/* Select Render 

*/ 

&GadgetText, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 


NULL, 

/* SpecialInfo 

*/ 

1, 

/* GadgetID 

*/ 

NULL, 

/* UserData 



>; 

Strukturbeschreibung 

Es handelt sich hier um ein Gadget des Typs Boolean, welches 
einen rechteckigen Klickbereich in der oberen linken Ecke des 
Windows haben wird. Das Gadget wird durch Umrandung des 
Bereiches selektiert dargestellt und ist erst nach einer Überprü¬ 
fung aktiviert. Das Gadget besitzt zur Kennzeichnung des 
Klickbereiches eine Border und einen Text, um die Bedeutung 
für den Benutzer deutlich zu machen. 


Neu ist der Wert GadgetID, unter dem wir eine Zahl von 0 bis 
65535 eintragen können. Diese Methode dient der Unterschei- 
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düng mehrerer Gadgets. Zur Gadget-Struktur fehlen noch die 
Ergänzungen, die Border-Struktur, die Koordinatentabelle und 
der Text. Hier sind sie: 

struct IntuiText GadgetText = 

< 

2, 0, JAM2, 4, 7, NULL, (UBYTE *)"Gadget" .NULL, 

>; 


SHORT GadgetPairst] = 

< 

0, 0. 61. 0. 61. 21. 0. 21. 0. 0. 

>; 


struct Borden GadgetBorder = 

i 

-1, -1, 1, 0, JAM1, 5, GadgetPairs, NULL, 

>; 

Fügen Sie alle neuen Programmteile in das Standardprogramm 1 
aus dem Kapitel "Windows" ein. Denken Sie daran, daß zuerst 
die IntuiText- und die Border-Struktur definiert werden müs¬ 
sen, bevor Sie die Gadget-Struktur einrichten können. Als letztes 
ergänzen wir in der Window-Struktur einen Pointer, der auf das 
erste User-Gadget weist. Die ganze Window-Struktur sollte dann 
etwa so aussehen: 


struct NewWindou FlrstNeuUindow = 
< 


160, 50, 

/* LeftEdge, TopEdge 


320, 200, 

/* Width, Height 


0, 1, 

/* DetailPen, BlockPen 

*/ 

CLOSEWINDOW | 

/* IDCMP Flags 

*/ 

GAOGETUP, 
WINOOWDEPTH \ 

/* Flags 

*/ 


WINDOUSIZING I 


WINDOWDRAG \ WINDOWCLOSE j 
SMART_REFRESH, 


&BoolGadget, 

/* First Gadget 

*/ 

NULL, 

/* CheckMark 

*/ 

(UBYTE ’*^)"Gadget- 

■Programmierung im Test", 


NULL, 

/* Screen 


NULL, 

/* BitMap 

*/ 

100, 50, 

/* Min Width, Height 

*/ 

640, 256, 

/* Max Width, Height 


WBENCHSCREEN, 

>; 

/* Type 
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Richten Sie Ihr Augenmerk auch auf das neue IDCMP-Flag, das 
uns über die Datenleitung immer Nachrichten senden wird, 
wenn ein Gadget angewählt wurde! 

Aus diesem Grund muß auch die Abfrage der IDCMP-Flags für 
diesen neuen Fall ergänzt werden. Nicht nur das Close-Gadget 
wird bei einer Nachricht untersucht, sondern auch die Möglich¬ 
keit, daß ein selbstdefiniertes Gadget angewählt wurde: 

FOREVER 

t 

if ((message == (struct IntuiMessage *) 

GetMsg(FirstWindow->UserPort)) == NULL) 
i 

WaitdL « FirstWindow->UserPort->mp_SigBit); 
continue; 

> 

MessageClass = message->Class; 

Code = message->Code; 

ReplyMsg(message); 
switch (MessageClass) 

< 

case GADGETUP : nr •►= 1; 

printf<"Gadget zum %d. Mal 

aktiviert!\n", nr); 

break; 

case CLOSEUINDOU : Close All(); 

exit(TRUE); 

break; 


> 


> 


Programmteil 3.2: Abfrageschleife Boolean-Gadget 

Die hier vorliegende Abfrageschleife bietet, im Gegensatz zu der 
bisher bekannten, noch einen weiteren großen Vorteil: 

Durch das Wait()-Kommando wird der Task in den Wait-Status 
gesetzt, bis ein Signal aufgetreten ist. Damit verbraucht die 
Schleife keine Prozessorzeit, wenn sie nichts zu tun hat. 

Die Abfrage des neu definierten Gadgets ist ziemlich einfach: 
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In der Switch()-Abfrage wird geprüft, ob ein selbstdefiniertes 
Gadget angewählt wurde. Da wir nur eines benutzen entfällt 
jede weitere Aussortierung, und wir können einen Zähler ausge¬ 
ben, der die Anzahl des Anklickens notiert. Vergessen Sie nicht, 
diese Variable vorher zu definieren! 

Programmbeschreibung 

Nach dem Starten des Programms erscheint ein Window auf dem 
Workbench-Screen, in dem sich ein Boolean-Gadget befindet. 
Das Programm bekommt nun jedesmal eine Nachricht, wenn Sie 
dieses Gadget mit der Action-Taste anklicken. Weil wir REL- 
VERIFY gesetzt haben, muß der Button auch im Klickbereich 
wieder losgelassen werden. Im DOS-Window wird dann ein Text 
mit der Anzahl des Anklickens ausgegeben. Das Programm kön¬ 
nen Sie mit dem Close-Gadget beenden. 

Abschließend läßt sich zu den Boolean-Gadgets sagen, daß sie 
immer gut für einfache Prozesse zu gebrauchen sind. Hiermit 
kann der Benutzer leicht etwas auslösen, bestätigen oder abbre¬ 
chen. 


3.4.1.2 Das Proportional-Gadget 

Alle weiteren Gadget-Typen setzen sich aus den Boolean-Gad¬ 
gets und einer kleinen Erweiterung zusammen, so auch das Pro¬ 
portional-Gadget. Wie Sie es von der Workbench her kennen, 
wird es dazu benutzt, Schiebebalken oder Objekte in einem Ka¬ 
sten einzurichten. Meistens hilft man sich damit bei Darstellun¬ 
gen, die größer sind, als es die Ausgabe erlaubt. Dann wird ein 
Schiebebalken benutzt, um die Größe des Ausschnitts wiederzu¬ 
geben und es dem Benutzer zu ermöglichen, einen anderen 
Ausschnitt zu wählen. Preferences benutzt ein zweidimensionales 
Proportional-Gadget, damit Sie die Lage des Ausgabebereiches 
festlegen können. Auch dafür eignet sich dieses Gadget. 

Nehmen wir also für unser erstes Proportional-Gadget eine ein¬ 
fache Gadget-Grundstruktur, die einen länglichen senkrechten 
Klickbereich hat; 
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struct Gadget PropGadget = 


NULL, 

/* NextGadget 

*/ 

100, 40, 

/* LeftEdge, TopEdge 

*/ 

20, 80, 

/* Width, Height 


GADGHCOMP, 

/* Flags 

*/ 

RELVERIFY, 

/* Activation 

*/ 

PROPGADGET, 

/* Gadget Type 


NULL, 

/* GadgetRender 

*/ 

NULL, 

/* Select Render 

*/ 

NULL, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 

*/ 

&BeispielProp, 

/* SpecialInfo 


2, 

/* GadgetID 


NULL 

/* UserData 

*/ 


>; 

Wie Sie unschwer erkennen, ist diese Struktur an Einstellungen 
wesentlich unterbelegt! Wir brauchen aber auch nicht so viele: 
Ein Text ist bei diesem Beispiel nicht nötig, und ein Rand um 
den "Container" wird bei Proportional-Gadgets von selbst ge¬ 
zeichnet, solange wir es nicht unterbinden. 


Allerdings haben wir nun den Wert Special Info belegt! Dieser 
Zeiger wird nämlich immer benutzt, wenn ein Boolean-Gadget 
nicht ausreicht. Dann zeigt er auf eine ergänzende Struktur. In 
unserem Fall benötigen wir eine Proplnfo-Struktur, die folgen¬ 
des Aussehen hat: 


Struct Proplnfo 
i 


0x00 

00 

USHORT 

Flags; 

0x02 

02 

USHORT 

HorizPot; 

0x04 

04 

USHORT 

VertPot; 

0x06 

06 

USHORT 

HorizBody; 

0x08 

08 

USHORT 

VertBody; 

OxOA 

10 

USHORT 

CWidth; 

OxOC 

12 

USHORT 

CHeight; 

OxOE 

14 

USHORT 

HPotRes; 

0x10 

16 

USHORT 

VPotRes; 

0x12 

18 

USHORT 

LeftBorder, 

0x14 

20 

USHORT 

TopBorder; 

0x16 

22 




>; 

Sie sehen, für ein Proportional-Gadget brauchen wir noch einige 
Daten mehr. Diese enthalten hauptsächlich die Ausmaße des 
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"Containers" und die des Schiebesymbols. Aber raten wir nicht 
lange, hier sind die Beschreibungen zu jedem Parameter: 

Flags 

Wieder ein Flag-Wert! Für das Proportional-Gadget brauchen 
wir noch ein paar Werte. Sie können wählen zwischen den fol¬ 
genden Einstellungen: 

AUTOKNOB 

Mit diesem Flag bestimmen Sie, daß Sie selbst kein Symbol für 
den Schieber definiert haben und Intuition ein Rechteck ver¬ 
wenden soll. Dieses Rechteck wird von Intuition erstellt und 
vollständig an jede Situation angepaßt. Die Größe des "knobs" 
können Sie über die nächsten beiden Werte in der Struktur be¬ 
stimmen. 

FREEHORIZ 

Wenn Sie dieses Flag setzen, kann der Schieber horizontal be¬ 
wegt werden. 

FREEVERT 

Wenn Sie dieses Flag setzen, kann der Schieber vertikal bewegt 
werden. Der Schieber kann in beide Richtungen bewegt werden, 
wenn Sie auch das FREEHORIZ-Flag setzen. 

KNOBHIT 

Dieses Flag können Sie nicht selber setzen. Es wird von Intuition 
gesetzt, wenn der Schieber gerade über die Maus angeklickt ist. 

PROPBORDERLESS 

Im Normalfall zeichnet Intuition einen Rand um den "Container". 
Durch dieses Flag wird das unterbunden. 

Nachdem Sie die gewünschten Flags gesetzt haben, dürfen Sie 
nicht vergessen, die anderen Werte der Struktur mit Angaben zu 
versehen. 
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HorizPot 

Gibt die horizontale Position des Schiebers an. 

VertPot 

Gibt die vertikale Position des Schiebers an. 

HorizBody 

Hiermit bestimmen Sie die "Sprungstärke" des Gadget-Schiebers. 
Damit wird die Weite bezeichnet, die der Schieber springt, wenn 
Sie in den "Container" klicken, aber nicht auf den Schieber 
selbst. 

Ver t Body 

Die gleiche Einstellung wie bei HorizBody, nur bezogen auf die 
vertikale Linie. 

Alle folgenden Werte brauchen nicht vom Programmierer einge¬ 
stellt zu werden. Sie werden von Intuition berechnet und können 
nach der Initialisierung des Gadgets abgefragt werden. 

CWidth 

Die Breite des "Containers", des Klickbereiches. 

CHeight 

Die Höhe des "Containers". 

HPotRes 

Auflösung des Schiebers in horizontaler Richtung. 

VPot Res 

Auflösung des Schiebers in vertikaler Richtung. 

LeftBorder 

Tatsächliche Position des linken Randes unseres "Containers". 
TopBorder 

Tatsächliche Position des oberen Randes unseres "Containers". 
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Für das Beispiel-Gadget sähe die Proplnfo-Struktur etwa so aus; 
struct Proplnfo BeispielProp = 


AUTOKNOB 1 FREEVERT, 

/* 

Flags 

*/ 

0x8000, 

/* 

HorizPot 

*/ 

0x8000, 

/* 

VertPot 

*/ 

0x0800, 

/* 

HorizBody 

*/ 

0x0800, 

/* 

VertBody 

*/ 

0. 

/* 

CUidth 

*/ 

0. 

/* 

CHeight 

*/ 

0. 

/* 

HPotRes 

*/ 

0. 

/* 

VPotRes 

*/ 

0, 

/* 

LeftBorder 

*/ 

0 

/* 

TopBorder 

*/ 


>; 

Alle Strukturen sind beisammen! Wir können sie in unser Pro¬ 
gramm einsetzen. Aber denken Sie daran, daß natürlich zuerst 
die Proplnfo-Struktur definiert werden muß, damit der Gadget- 
Struktur der Wert von BeispielProp bekannt ist. Gleiches gilt 
natürlich für die Window-Struktur, in die die Adresse der Gad- 
get-Struktur "eingepflanzt” wird. 

Wenn Sie dies alles befolgt haben, ist die Arbeit leider immer 
noch nicht abgeschlossen! Wir bekommen bei einem Proportio- 
nal-Gadget keine Nachricht, daß ein Gadget "niedergedrückt” 
wurde (GADGETDOWN), sondern erhalten die Information, 
wenn das Gadget losgelassen wurde (GADGETUP). Dies wird ab 
jetzt in der Schleife auch noch berücksichtigt: 

FOREVER 

C 

if ((message = (struct IntuiMessage 

GetMsg(FirstWindow->UserPort)) == NULL) 

C 

WalteIL « FirstWindow->UserPort->mp_SigBit); 
continue; 

> 

MessageClass = message->Class; 

Code = message->Code; 

ReplyMsg(message); 
switch (MessageClass) 

< 

case GADGETUP : printf("Position: u%\n", 

BeispielProp.VertPot); 


break; 
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case CLOSEUINDOU : Close_AU(); 

exit(TRUE); 

break; 

case GADGETDOWN : nr += 1; 

printfC'Gadget zum %d. Mal 

aktiviert!\n", nr); 

break; 


> 


> 


Programmteil 3.3: Abfrageschleife Proportional-Gadget 


3.4.1.3 Das String-Gadget 

String-Gadgets sind, genau wie Proportional-Gadgets, eine Wei¬ 
terentwicklung der Boolean-Gadgets. Wie man sich leicht denken 
kann, fügen wir nicht eine Proplnfo-Struktur an, sondern eine 
Stringlnfo-Struktur. Diese ist etwa gleich lang und enthält alle 
zusätzlichen Informationen, die ein String-Gadget benötigt. 

Dieses String-Gadget haben Sie bestimmt schon einmal benutzt! 
Selbst die Workbench bietet eines an. Wenn Sie z.B. den Namen 
eines Files oder einer Diskette ändern, fahren Sie den Punkt Re- 
name im Workbench-Menü an. Dann erscheint ein Fenster, in 
dem Sie den Namen korrigieren können. Das ist ein String-Gad¬ 
get. In diesem Fall hat das Fenster auch die Größe des Gadgets, 
aber das ist nicht so wichtig. 

Viel wichtiger ist, daß wir für ein String-Gadget ebenso eine 
Gadget-Struktur einrichten müssen wie für jedes andere Gadget 
auch. Dafür müssen Sie einen waagerechten Klickbereich defi¬ 
nieren, denn die Texteingabe ist nur einzeilig möglich. 


struct Gadget StringGadget = 

{ 

NULL, /• NextGadget */ 

50, 40, /* LeftEdge, TopEdge */ 

120, 10, /* Width, Height */ 

GADGHCOHP, /* Flags */ 

RELVERIFY | /* Activation */ 

STRINGCENTER, 

STRGADGET, /* Gadget Type */ 
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(APTR)&GadgetBorder, 

/* GadgetRender 

*/ 

NULL, 

/* Select Render 

*/ 

&GadgetText, 

/* GadgetText 

*/ 

NULL, 

/* HutualExclude 

*/ 

(APTR)&StringInfo, 

/* SpecialInfo 

*/ 

3, 

/* GadgetID 

*/ 

NULL 

>; 

/* UserData 

*/ 


Einige Variablen bekommen bei String-Gadgets noch eine zu¬ 
sätzliche oder andere Bedeutung. Da ist zuerst das Flags-Flag. Es 
beschreibt nun das Aussehen des Cursors und nicht mehr das 
Aufblinken des ganzen Klickbereiches. 

Unter dem Punkt Activation sind jetzt vier weitere Flags sinn¬ 
voll: 

STRINGCENTER 

Setzen Sie dieses Flag, wenn Sie möchten, daß der Text im Ein¬ 
gabefeld immer zentriert ausgegeben werden soll. 

STRINGRIGHT 

Setzen Sie dieses Flag, wenn Sie möchten, daß der Text immer 
zum rechten Rand ausgerichtet werden soll. 

Hinweis: Die normale Einstellung bewirkt, daß der Text im¬ 

mer zum linken Rand ausgerichtet wird. Dafür müs¬ 
sen Sie kein Flag setzen. 


LONGINT 

Dieses Flag kennzeichnet ein Integer-Gadget. Dieser Typ erlaubt 
es dem Benutzer nur noch, Zahlenwerte einzugeben. 

ALTKEYMÄP 

Für die Eingabe wird die allgemein definierte Tastaturtabelle 
verwendet. Wollen Sie eine andere zur Verfügung haben, so set¬ 
zen Sie dieses Flag, und ergänzen Sie den Wert AltKeyMap in 
der Stringlnfo-Struktur. 

Nachdem wir den Gadget-Typ mit STRGADGET spezifiziert 
haben, dürfen wir nicht vergessen, den Klickbereich durch eine 
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Grafik anzudeuten. Denn nur bei Proportional-Gadgets wird 
automatisch ein Rand gezeichnet. Ich verwende hier eine einfa¬ 
che Border-Struktur ohne viel Aufwand: 

SHORT GadgetPairst] = 

0 , 0 , 122 , 0 . 122 , 12 , 0 . 12 , 0 , 0 , 

>; 

struct Border GadgetBorder = 

C 

-2, -2, 1, 0, JAM1, 5, GadgetPairs, NULL, 

>; 


Sie können die Textzeile aber auch einfach durch einen Unter¬ 
strich kennzeichnen und müssen nicht einen ganzen Kasten 
nehmen. Der Gadget-Text ist zwar nicht nötig. Sie sollten ihn 
aber verwenden, damit der Benutzer immer weiß, was er dort 
eingeben soll: 

struct IntuiText GadgetText = 

< 

2, 0, JAM2, -40, 1, NULL, (UBYTE *)"Text" .NULL, 

>; 


Als letzte erwähnenswerte Ergänzung enthält unsere Struktur den 
Zeiger auf das String Info. Diese neue Struktur enthält folgende 
Parameter: 


Struct Stringinfo 

r 

0x00 

00 

UBYTE *Buffer; 

0x04 

04 

UBYTE *UndoBuffer; 

0x08 

08 

SHORT BufferPos; 

OxOA 

10 

SHORT MaxChars; 

OxOC 

12 

SHORT DispPos; 

OxOE 

14 

SHORT UndoPos; 

0x10 

16 

SHORT NumChars; 

0x12 

18 

SHORT DispCount; 

0x14 

20 

SHORT CLeft; 

0x16 

22 

SHORT CTop; 

0x18 

24 

struct Layer *LayerPtr; 

OxIC 

28 

LONG Longint; 

0x20 

32 

struct KeyMap *AltlCeyMap; 

0x24 

36 



>; 
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Gleich die beiden ersten Werte sind eigentlich die wichtigsten. 
Sie zeigen jeweils auf einen Puffer, in dem die Zeichenketten 
untergebracht werden. Der erste Puffer enthält den Text, der 
wirklich eingegeben wurde. Der zweite Puffer ist für den Be¬ 
nutzer als Komfort gedacht. Dadurch ist es mit einem Tasten¬ 
druck möglich, die Veränderung, die man am Text vorgenom¬ 
men hat, rückgängig zu machen. 

Solch einen Puffer können wir uns ganz schnell besorgen. Dafür 
definieren wir einfach ein Feld mit der entsprechenden Anzahl 
an Zeichen. Das sieht dann so aus: 

#define STRINGSIZE 80 

unsigned char StringBuffer[STRINGSIZE] = "Hallo Amiga!"; 
unsigned char UndoBuffer [STRINGSIZE]; 

Es ist nicht unbedingt vorgeschrieben, einen UndoBuffer einzu¬ 
richten. Allerdings hat der Benutzer dann auch nicht die Mög¬ 
lichkeit, seinen Text über diese Funktion zu korrigieren. 

Mit BufferPos können Sie bei Initialisierung der Struktur den 
Cursor an eine bestimmte Stelle setzen. Dies ist interessant, wenn 
beim Aufruf schon ein Text im Puffer steht, wie im obigen 
Beispiel. 

Da Intuition natürlich nicht weiß, wie groß der Textpuffer ein¬ 
gerichtet wurde, gibt man unter MaxChars an, wie viele Zeichen 
eingegeben werden dürfen. Es ist darauf zu achten, daß bei der 
Länge der Zeichenkette auch noch das abschließende NULL- 
Byte mitgezählt werden muß, denn es handelt sich hier um einen 
String! 

Der letzte vom Programmierer einzustellende Wert ist DispPos. 
Die Nummer, die Intuition dort wiederfindet, kennzeichnet das 
erste Zeichen, das im Display-Feld ausgegeben wird. 

Alle weiteren Werte werden von Intuition selbst verwaltet und 
berechnet. Sie können diese für Informationen abfragen. 
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UndoPos 

Die Position des Cursors im UndoBuffer. 

NumChars 

Die Anzahl der Zeichen, die sich momentan im Puffer befinden. 
DispComt 

Die Anzahl der Zeichen, die im Klickbereich dargestellt werden 
können. 

CLeft 

Der Offset des "Containers" zum linken Fensterrand. 

CTop 

Der Offset des "Containers" zum oberen Fensterrand. 

LayerPtr 

Ein Zeiger auf den Layer, in dem dieses Gadget untergebracht 
ist. 

Longint 

Hier steht bei einem Integer-Gadget - nach dem Return-Druck 
- die eingegebene Zahl. Sie können sie auslesen und dann wei¬ 
terverarbeiten. 

AltKeyMap 

Wie oben schon erwähnt, können Sie hier einen Zeiger auf eine 
eigene Tastaturtabelle einsetzen, die dann für die Eingabe ver¬ 
wendet wird. 

Wenden wir uns wieder der praktischen Anwendung zu. Bauen 
Sie dafür in unser Standardprogramm die Gadget-, die 
Stringinfo- und die restlichen Strukturen ein. 

Alle Definitionen müßten zusammen folgendermaßen aussehen: 
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«define STRINGSIZE 80 

unsigned char StringBuffer[STRINGSIZE] = "Hallo Amiga! 
unsigned char UndoBuffer [STRINGSIZE]; 

struct StringInfo Stringinfo = 
i 


&StringBuffer[0], 

/* Buffer 

*/ 

SUndoBufferCO], 

/* Undo Buffer 

*/ 

0. 

/* Buffer Position 

*/ 

STRINGSIZE, 

/* MaxChars 

*/ 

0, 

/* Display Positoin 

*/ 

0, 

/* Undo Position 


0. 

/* NumChars 

*/ 

0, 

/* Display Counter 

*/ 

0. 0, 

/* CLeft, CTop 

*/ 

NULL, 

/* LayerPtr 

*/ 

0. 

/* Longint 


NULL 

/* AltKeyMap 

*/ 


>; 

SHORT GadgetPairsn = 
i 

0 , 0 , 122 , 0 , 122 , 12 , 0 , 12 , 0 , 0 

>; 

struct Border GadgetBorder = 

-2, -2, 1, 0, JAM1, 5, GadgetPairs, NULL 

>; 

struct IntuiText GadgetText = 

C 

2, 0, JAM2, -40, 1, NULL, (UBYTE ♦)"Text" ,NULL 

>; 

struct Gadget StringGadget = 
i 


NULL, 

/* NextGadget 

*i 

50, 40, 

/* LeftEdge, TopEdge 


120, 10, 

/* Width, Height 


GADGHCOMP, 

/♦ Flags 

*/ 

RELVERIFY | 
STRINGCENTER, 

/* Activation 


STRGADGET, 

/* Gadget Type 


(APTR)&GadgetBorder, 

!* GadgetRender 

*/ 

NULL, 

/* Select Render 


&GadgetText, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 


(APTR)&StringInfo, 

/* Speciallnfo 

*/ 

1r 

/* GadgetID 

*/ 

NULL 

>; 

/* UserData 

*/ 
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struct NewUindow FirstNewUindow s 
i 


160, 50, 

/* LeftEdge, TopEdge 

*/ 

320, 200, 

/* Uidth, Height 

*/ 

0, 1, 

/* OetailPen, BloekPen */ 

CLOSEUINDOU j 

/* IDCNP Flags 

*/ 

GADGETUP, 
UINDOUDEPTH j 

/* Flags 

*/ 


WINDOUSIZING j 


WINDOUDRAG | 
WINDOUCLOSE | 
SMART_REFRESH, 


&StringGadget, 

/* First Gadget 

*/ 

NULL, 

/* CheckMark 


*/ 

(UBYTE •)"String-Gaclget Test“, 



NULL, 

/* Screen 


*/ 

NULL, 

/* BitMap 



100, 50, 

/* Min Width, 

Height 

*/ 

640, 256, 

/* Max Width, 

Height 

*/ 

UBENCHSCREEN 

>; 

/* Type 




Für das Programm verwenden wir eine etwas abgeänderte Ab¬ 
frage-Schleife der Gadgets: 

switch (MessageClass) 

{ 

case GADGETUP : printfC'Der Text heißt: Xs\n", 

&StringBuffer[0]); 

break; 

case CLOSEWINOOU : Close AHO; 

exit(TRUE); 

break; 

> 


Programmbeschreibung 

In das Fenster wurde ein String-Gadget eingebaut, in dem Sie 
nach dem Anklicken den Text editieren können. Nach dem 
Druck auf die Return-Taste gibt das Programm den eingegebe¬ 
nen Text im DOS-Window aus. 


Für jeden Return-Druck in einem String-Gadget erhält das Pro¬ 
gramm eine GADGETUP-Nachricht auf der Datenleitung. Diese 
kann als Bestätigung angesehen werden, denn die Eingabe ist 
dann abgeschlossen. 
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3.4.2 Gadgets in Aktion 

Mit den drei eben beschriebenen Gadget-Typen lassen sich nun 
die vielfältigsten Anwendungen gestalten. 

Einmal sind Gadgets durch ihre Symbolik besonders wirkungs¬ 
voll. Wir können damit ganz einfach die Prozeßauslösung steu¬ 
ern. Aber auch String- und Proportional-Gadgets sind nicht 
ohne. Wir wollen uns deshalb mit einigen Anwendungs-Beispie¬ 
len beschäftigen, die sich einerseits in jedes andere Programm 
einbauen lassen, die aber auch im besonderen für unseren Editor 
geeignet sind. 

Bisher wurden die Gadgets immer in die NewWindow-Struktur 
mit eingebunden, und das Programm hatte deshalb keine Sorgen 
mit der Verarbeitung. Dieses kann sich aber auch ändern, denn 
nicht immer ist es der Fall, daß gleich beim öffnen des Fensters 
alle Gadgets gebraucht werden. Oft kommt es vor, daß nach und 
nach einige Gadgets in das Fenster eingefügt werden. Dafür und 
für vieles mehr stehen die Gadget-Funktionen zur Verfügung. 
Sie sind ein weiteres Themengebiet wert. 

Das wohl größte Anwendungsgebiet der Gadgets sind die Re- 
quester. Das sind Ansammlungen vieler Gadgets in einem Sinn¬ 
zusammenhang. Da wir dafür viele Gadgets brauchen, will ich 
Ihnen dazu schon einige Anwendungen vorstellen, die sich dann 
im Requester-Kapitel vervollständigen werden. 


3.4.2.1 Die Gadget-Funktionen 

Wir wollen uns zuerst mit dem oben angesprochenen Problem 
beschäftigen, daß die Gadgets nicht immer gleich beim öffnen 
des Fensters erwünscht sind. In manchen Programmen kann es 
wünschenswert sein, daß ein Gadget bei Bedarf in das Window 
eingefügt wird. Auch dafür stellt Intuition viele Funktionen zur 
Verfügung. 

Betrachten wir zuerst den Fall, daß ein Window geöffnet wird, 
wie es auch das Standardprogramm 1 macht. Dann, nachdem et- 
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was Zeit vergangen ist, denn wir haben noch keine Programm¬ 
ausführung, wird ein Gadget in die Window-Struktur eingebun¬ 
den und auf dem Bildschirm dargestellt. 

Ich beschreibe den Vorgang in Einzelschritten, weil wir in den 
gleichen Einzelschritten in der Programmierung vergehen müs¬ 
sen. Als Grundprogramm verwenden Sie bitte das Standardpro¬ 
gramm 1 mit der globalen NewWindow-Struktur. Definieren Sie 
mit der nachfolgenden Gadget-Struktur ein Toggle-Gadget, das 
Sie aber nicht in die NewWindow-Struktur einbinden. 

SHORT GadgetPairsC] = 

< 

0, 0, 61, 0. 61, 21, 0, 21, 0, 0 
>; 


struct Border GadgetBorder = 

{ 

-1, -1, 1, 0, JAM1, 5, GadgetPairs, NULL 
>; 

struct IntuiText ToggleText = 

< 

3, 0, JAM2, 4, 7, NULL, (UBYTE »T'^Toggle" ,NULL 
>; 

struct Gadget ToggleGadget = 


NULL, 

/* NextGadget 


120, 40, 

/* LeftEdge, TopEdge 

*/ 

60, 20, 

/* Width, Height 

*/ 

GADGHBOX, 

/* Flags 

*/ 

RELVERIFY j 
TOGGLESELECT, 

/♦ Activation 

*/ 

BOOLGADGET, 

/* Gadget Type 


(APTR)&GadgetBorder, 

/* GadgetRender 


NULL, 

/* Select Render 

*/ 

&ToggleText, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 


NULL, 

/* SpecialInfo 

♦/ 

1, 

/* GadgetID 

*/ 

NULL 

>; 

/* UserData 



Struktur 3.11: Toggle-Gadget 

Weil eventuell einige Leser noch kein Toggle-Gadget kennen, 
habe ich hier diesen Typ gewählt. Es ist ein Gadget, das bei 
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einmaligem Anklicken in den "selected"-Status übergeht und bei 
erneutem Anklicken wieder "unselected" wird. 

Wollen wir jetzt dieses Gadget nachträglich in das Window ein¬ 
binden, müssen wir eine Intuition-Funktion dafür benutzen. Sie 
trägt den Namen AddGadget() und hat folgende Syntax; 

RealPosition ^ AddGadgettWindow, Gadget, Position); 

DO -42 AO A1 DO 

Wir übermitteln zuerst das Window, in das das Gadget eingefügt 
werden soll, und natürlich die Adresse des Gadgets selbst. Als 
nächstes können wir, aufgrund großer Freizügigkeit im Be¬ 
triebssystem, sogar noch die Position bestimmen, die es in der 
Liste einnehmen soll. Als Ergebnis bekommen wir die wirklich 
erlangte Position zurück. 

Für unser Toggle-Gadget würde das Kommando so aussehen: 

Pos s AddGadgetCFirstWindow, ToggleGadget, *1L); 

Mit der -1 erklären wir, daß das Gadget als letztes in die Liste 
eingefügt werden soll. 

Mit diesem Funktionsaufruf ist das Gadget zwar in die Liste des 
Windows übernommen, sehen kann es der Programmbenutzer 
aber immer noch nicht. Dafür bedarf es einer zusätzlichen 
Funktion, die sonst beim Einrichten eines neuen Fensters auto¬ 
matisch aufgerufen wird. Wir rufen sie ganz einfach unter ihrem 
Namen auf: 

RefreshGadgetsCGadgets, Window, Requester); 

-222 AO A1 A2 

Diese Funktion zeichnet alle angegebenen Gadgets in der Win¬ 
dow-Liste neu. Damit nicht alle neu ausgegeben werden - das ist 
ja nicht immer nötig -, bestimmen wir mit Gadgets, ab welchem 
Gadget die Routine beginnen soll. Deswegen haben wir unser 
neues Gadget auch ans Ende der Liste gehängt. Geben wir seine 
Nummer an, wird nur dieses neu gezeichnet und kein anderes. 
Man muß nämlich wissen, daß das Neuzeichnen Zeit in An- 
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Spruch nimmt und außerdem sichtbar ist, weil die Grafik vorher 
gelöscht wird. 

Fügen wir hinter den AddGadget()-Befehl RefreshGadgets() ein: 

RefreshGadgetsCPos, FirstUlndow, NULL); 

Damit ist auch das Gadget sichtbar, das wir erst nachträglich 
eingefügt haben. Nun sehen wir uns noch die Abfrage eines 
Toggle-Gadgets an: 

FOREVER 

{ 

if ((message = (struct IntuiMessage *) 

GetMsg(FirstWindow->UserPort)) == NULL) 

< 

WaitdL « FirstWitxlow->UserPort->mp_SigBit); 
continue; 

> 

MessageClass = message*>Class; 

Code = message->Code; 

GadgetPtr = (struct Gadget *) message->IAddress; 

SelectMode= GadgetPtr->Flags & SELECTED; 

ReplyMsg(message); 
switch (MessageClass) 

C 

case GAOGETUP : if (SelectMode) 

L 

printf("aktiviert "); 

> 

eise 

i 

printf("deaktivier\n"); 

> 

break; 

case CLOSEWINDOU : Close.AllO; 

exit(TRUE); 

break; 

> 

> 


Programmteil 3.4: Abfrageschleife Toggle-Gadgets/Select-Mode 


Die Überprüfung, ob ein Gadget niedergedrückt wurde, ist noch 
um eine Unterscheidung reicher geworden. Auch der Status des 
Gadgets wird jetzt untersucht, und zwar auf "selected" oder 
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"unselected". Durch eine einfache UND-Verknüpfung ließ sich 
das realisieren. Jetzt gibt das Programm in das DOS-Window 
aus, welchen Status das Gadget hat. 

Im Moment hat dieses neue Toggle-Gadget noch keine weitere 
Funktion. Was könnte dieses Gadget ein- und ausschalten? Die 
Antwort ist ganz einfach. Ein anderes Gadget! Wir fügen ein 
neues Gadget hinzu und lassen es vom Toggle-Gadget ein- und 
ausschalten. Damit lernen wir sogar noch zwei neue Funktionen 
kennen. Als zweites Gadget wählen wir ein ganz normales Boo- 
lean-Gadget, um möglichst wenig Aufwand zu betreiben. Hier 
ist auch gleich die Struktur: 

SHORT SelectPairsn = 

<. 

0, 0. 61, 0, 61. 21. 0. 21, 0. 0. 

>; 

struct Border SelectBorder = 

-1, -1, 1, 0, JAM1, 5, SelectPairs, NULL, 

>; 


struct IntuiText SelectText = 
i 

1, 0, JAM2, 4, 7, NULL, (UBYTE *)”Select" ,NULL, 
>; 


struct Gadget SeiectGadget = 


C 


NULL, 

/* NextGadget 

*/ 

10, 40, 

/* LeftEdge, TopEdge 

*/ 

60, 20, 

/* Uidth, Height 

*/ 

GADGHCOMP | 
GADGDISABLED, 

/* Flags 

*/ 

RELVERIFY, 

/* Activatiön 

*/ 

BCXDLGADGET, 

/* Gadget Type 

*/ 

(APTR)&SelectBorder, 

/* GadgetRender 

*/ 

NULL, 

/* Select Render 

*/ 

&SelectText, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 

*/ 

NULL, 

/* SpecialInfo 

*/ 

2, 

/* GadgetID 

*/ 

NULL 

>; 

/* UserData 



Struktur 3.12: Select-Gadget 
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(Wenn Sie wollen, können Sie jedes andere Gadget nehmen!) 
Strukturbeschreibmg 

Wie gewohnt, habe ich Ihnen auch die Border- und die Intui- 
Text-Struktur gleich mitgeliefert, damit Sie in den weniger 
wichtigen Gebieten keine Arbeit haben. Richten wir unser Au¬ 
genmerk jetzt auf das Select-Gadget. 

Es handelt sich hierbei um ein ganz normales Boolean-Gadget 
mit der Besonderheit, daß es "disabled" ist. Es wurde durch das 
Flag GADGDISABLED in einen Zustand versetzt, der es für den 
Anwender unmöglich macht, es anzuwählen. 

Dabei wird der ganze Klickbereich mit einem Raster überdeckt. 
Man nennt diesen grafischen Zustand auch "ghosted". 

Auch dieses zweite Gadget muß dem Window "angehängt" wer¬ 
den. Dazu könnten wir noch einen weiteren AddGadget()-Befehl 
einbauen. Aber Intuition bietet auch für den Fall, daß mehrere 
Gadgets eingebunden werden müssen, eine weitere Funktion. 
Mit AddGListO können wir ganze Listen von Gadgets, die ein¬ 
fach gelinkt sind, in die Window-Liste einbinden. Setzen Sie 
dafür in das erste Gadget einen Zeiger auf das zweite. Jetzt 
können Sie mit 

RealPosition = AddGListCUindow, Gadget, Position, Numgad, 

DO -438 AO A1 DO Dl 

Requester); 

D2 

die beiden Gadgets in unsere Window-Liste einfügen. Dafür sind 
die ersten drei Parameter bereits von der einfachen Funktion 
bekannt. Duch Numgad geben Sie an, wie viele Gadgets die Li¬ 
ste enthält, und der Requester muß auf den Requester zeigen, 
wenn wir einen benutzen. Das machen wir aber nicht! Also den 
Wert mit Null belegen. 
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Das gleiche Problem, das wir mit AddGadget() hatten, tritt auch 
bei RefreshGadgetsO auf. Über AddGListO erfahren wir die 
Position unseres ersten Gadgets. Diese geben wir auch bei der 
Refresh-Funktion an, jedoch sollen ja insgesamt nur zwei Gad¬ 
gets neu gezeichnet werden. Deshalb gibt es auch einen Listen- 
Befehl zum Refresh: 

RefreshGList(Gadgets, Window, Requester, Numgad); 

-432 AO A1 A2 DO 

Analog zur AddGList-Funktion wird auch hier mit Numgad 
eingestellt, wie viele Gadgets einem Refresh unterworfen werden 
sollen. 

Kehren wir jetzt zurück zu unserem Programm. Es soll nun das 
Boolean-Gadget wieder freigegeben werden, wenn das Toggle- 
Gadget aktiviert wurde und umgekehrt. Dafür müssen wir zuerst 
die beiden selbstdefinierten unterscheiden können. Hier hilft uns 
die GadgetlDl Mit der Nummer, die wir dort eintragen können, 
ist es uns möglich, jedes Gadget zu Identifizieren. Wählen Sie 
deshalb in einem Programm möglichst verschiedene Nummern. 

Dementsprechend muß jetzt auch die Abfrage geändert werden. 
Doch zuvor sollen Sie die beiden Funktionen kennenlernen, mit 
denen wir den Status beeinflussen können. Es sind dies: 

OffGadgetCGadget, Window, Requester); 

-174 AO AI A2 


und 


OnGadgetCGadget, Window, Requester); 

-186 AO AI A2 

Beide Funktionen benötigen die gleichen Parameter: einen Zeiger 
auf das Gadget, dessen Status geändert werden soll, den Zeiger 
auf das Window, in dem sich das Gadget befindet, und einen 
Zeiger auf einen Requester, wenn er vorhanden ist. Die letzte 
Variable ist für uns momentan noch uninteressant. 

Wir brauchen die Abfrage nur dahingehend zu verändern, daß 
wir bei einem positiven Test des SELECT-Flags OnGadgetO 
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auf rufen und bei ungesetztem Flag OffGadget(). Jedesmal über¬ 
geben wir einen Zeiger auf das Select-Gadget: 

switch (GadgetNr) 

C 

case 2 : printf("selected!\n"); 

break; 

case 1 : if (selectmode) 

C 

printf("aktiviert "); 

OnGadget(&SelectGadget, FirstWindow,NULL); 
RefreshGadgetsC&SelectGadget, 

FirstWindow,NULL); 

> 

eise 

C 

print f("deaktivier\n"); 

OffGadgetC&SelectGadget, FirstWindow,NULL); 

> 

break; 

> 

break; 

Programmteil 3.5: Abfrageteil GadgetOn/Off 

Diese Ergänzung fügen Sie bitte anstatt der If-Abfrage beim 
case GADGETUP ein. Zusätzlich müssen Sie die USHORT-Va¬ 
riable GadgetNr vorher berechnen lassen: 

GadgetNr = GadgetPtr->GadgetID; 

Programmbeschreibung 

Wenn Sie alle neuen Teile im ersten Programm ergänzt haben, 
sollte sich Ihnen folgendes Bild bieten: 

Ein Fenster mit zwei Gadgets: Das rechte Gadget zum Ein- und 
Ausschalten und ein weiteres Gadget, das zuerst "ghosted" darge¬ 
stellt ist. Klicken Sie nun auf das rechte Gadget, so sollte we¬ 
nigstens die Schrift des anderen wieder leserlich sein. Jetzt kön¬ 
nen Sie auch dieses Gadget anklicken. Das Programm zeigt seine 
Reaktionen über Texte im DOS-Window. Für das Toggle-Gadget 
erscheinen Texte wie "aktiviert" und "deaktiviert". Nur wenn Sie 
das linke Gadget anklicken können, sendet das Programm den 
Text "selected!". 
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Nachdem wir uns so ausführlich mit den Boolean-Gadgets be¬ 
schäftigt haben, werden nun auch die anderen beiden Typen 
beschrieben: 


Zuerst soll unsere Aufmerksamkeit dem Proportional-Gadget 
gelten, für das es sogar zwei spezielle Funktionen gibt. In diesem 
Beispiel soll das Gadget nicht mit dem Autoknob versehen wer¬ 
den, sondern mit einer eigenen Grafik. Hier ist die dazugehörige 
Image-Struktur mit den Grafikdaten: 

USHORT KnobGrafikn = 

C 

OxCCCC, 

0x6666, 

0x3333, 

0x9999, 

OxCCCC, 

0x6666, 

0x3333, 

0x9999, 

OxCCCC, 

0x6666, 

0x3333, 

0x9999, 

OxCCCC, 

0x6666, 

0x3333, 

0x9999 

>; 

struct Image Knob = 

C 

0 , 0 , 

16, 16, 

1 , 

&KnobGrafik[03, 

1 , 0 , 

NULL 

>; 


Zu dieser Grafik gehört natürlich die Gadget-Struktur mit der 
Erweiterung durch Proplnfo: 

Struct Proplnfo SchieberProp = 

C 


FREEVERT, 

/* 

Flags 

*/ 

0x8000, 

/* 

HorizPot 

*/ 

0x8000, 

/* 

VertPot 

*/ 

0x0800, 

/* 

HorizBody 

*/ 
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0x1000, 

/* VertBody 

*/ 

0. 

/* CWidth 

*/ 

0, 

/* CHeight 

*/ 

0, 

/* HPotRes 

*/ 

0. 

/* VPotRes 

*/ 

0. 

LeftBorder 

*/ 

0 

>; 

/* TopBorder 

*/ 

struct Gadget Schieber = 

r 



V 

NULL, 

/* NextGadget 

*/ 

260, 40, 

/* LeftEdge, TopEdge 

*/ 

24, 120, 

/* Uidth, Height 

*/ 

GADGHNONE | 

/* Flags 

*/ 

GADGIMAGE, 

RELVERIFY, 

/* Activation 

*/ 

PROPGADGET, 

/* Gadget Type 

*/ 

(APTR)&Knob, 

/* GadgetRender 

*/ 

NULL, 

/* Select Render 

*/ 

NULL, 

/* GadgetText 


NULL, 

/* MutualExclixJe 

*/ 

(APTR)&Sch 1 eberProp, 

/* Special Info 

*/ 

L 

/* GadgetID 

*/ 

NULL 

/* UserData 



>; 

Struktur 3.12: Proportional-Gadget: Schieber 

Hinweis: Beachten Sie, daß die Grafikdaten des Schiebers im 

Chip-Memory abgelegt werden müssen. 

Bevor das Programm startfertig ist, sollten wir noch eine kleine 
Ergänzung machen, um wenigstens die Position des Schiebers 
untersuchen und auswerten zu können. Setzen Sie diese zwei 
Zeilen in die Gadget-Abfrage ein: 

case GADGETUP : printfC'Schieber-Position: %x\n", 

SchieberProp. VertPot); 

break; 

Wir können nun in einer Anwendung die Position des Schiebers 
im Programm abfragen und auswerten. Allerdings gibt es auch 
Situationen, in denen es wichtig ist, die Lage des Schiebers 
durch das Programm zu verändern, z.B. die Größe oder ähnli¬ 
ches. Grundsätzlich ist das auch alles zugelassen. Zuerst möchte 
ich eine Methode beschreiben, die sich auf jedes Gadget bezieht 
und die Sie auch bei jedem Typ einmal ausprobieren sollten! 
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Danach erkläre ich noch zwei Funktionen, die, wie oben schon 
angedeutet, extra für Proportional-Gadgets eingerichtet wurden. 

Zur allgemeinen Methode: Um irgendwelche Einstellungen an 
einem Gadget zu ändern, ist es zuerst nötig, dieses Gadget wie¬ 
der aus der Liste des Windows zu entfernen. Wird dies nicht 
gemacht, dann treten Fehler auf! Demnach benötigen wir als er¬ 
stes eine Funktion, die es erlaubt, ein Gadget wieder aus der 
Liste zu nehmen. Mit RemoveGadget() ist das kein Problem: 

Position = RemoveGadget(Window, Gadget); 

DO -228 AO AI 

Nehmen wir als Beispiel das Proportional-Gadget. Es läßt sich 
ganz einfach mit folgendem Befehl wieder entfernen: 

Pos = RemoveGadgetCFirstwindow, Schieber); 

Jetzt können wir an der Gadget-Struktur, an der Proplnfo- 
Struktur und allen angebundenen Strukturen Veränderungen 
vornehmen. Danach läßt es sich wieder über AddGadget() in die 
Liste eingliedern. Zum Schluß müssen Sie noch über Refresh- 
GadgetsO das Aussehen des Gadgets aktualisieren, damit die 
Ausgabe auf dem neuesten Stand ist. 

In anderen Fällen, in denen ganze Mengen von Gadgets entfernt, 
geändert und wieder in die Liste eingetragen werden, gibt es 
noch einen zusätzlichen Befehl: 

Position = RetnoveGListtWindow, Gadget, Numgad); 

DO -444 AO AI DO 

Hier geben Sie zusätzlich die Anzahl der Gadgets an, die ent¬ 
fernt werden sollen. Das Gegenstück, AddGList(), ist Ihnen be¬ 
reits bekannt. Vergessen Sie auch hier nicht, mit RefreshGList() 
die Grafik zu aktualisieren. 

Der zweite Weg, der ausschließlich für Proportional-Gadgets ge¬ 
dacht ist, erspart uns den Aufwand, jedes Gadget aus der Liste 
zu lösen und dann wieder einzufügen. Mit der Funktion Mo- 
difyPropO können wir, nach Angabe des Gadgets, alle vom Be¬ 
nutzer möglichen Einstellungen der Proplnfo-Struktur wieder 
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verändern. Das Gadget wird danach automatisch wieder neu ge¬ 
zeichnet. 

ModifyProp(Gadget, Window, Requester, Flags, HorizPot, VertPot, 
-156 AO A1 A2 DO Dl D2 

HorizBody, VertBody); 

D3 D4 

Leider hat diese Funktion einen kleinen Nachteil: In manchen 
Anwendungen ist es ziemlich oft nötig, über ModifyPropO die 
Einstellungen zu ändern. Da die Funktion aber auf RefreshGad- 
gets() zurückgreift, werden alle nachfolgenden Gadgets in der 
Liste auch "refreshed". Das ist störend, und deshalb wurde New- 
ModifyPropO zu den Intuition-Funktionen auf genommen. 

NewModifyProptGadget, Window, Requester, Flags, HorizPot, VertPot, 
-468 AO AI A2 DO Dl D2 

HorizBody, VertBody, Numgad); 

D3 D4 D5 

Bei der neuen Funktion, die genau die gleiche Aufgabe hat, 
können Sie noch wählen, wie viele Gadgets in der Liste "refres¬ 
hed" werden sollen. Als geeignetsten Wert empfehle ich hier 1, 
es sei denn. Sie haben noch einige Gadgets, die von der Verän¬ 
derung betroffen sind und gleich mitbearbeitet werden sollen. 

Sehen Sie sich als nächstes folgendes Problem an: Wir haben im 
Window eine Liste von Namen, die untereinander geschrieben 
wurden. Sie möchten nun, daß der Benutzer einen dieser Namen 
aussuchen kann. Wie könnten wir dieses Problem lösen? 

Zuerst fragen Sie sich natürlich, wann so ein Fall überhaupt 
auftreten könnte. Denken Sie doch einmal an eine File-Select- 
Box. Da haben wir eine Liste von File-Namen, aus denen wir 
uns einen aussuchen sollen. Das gleiche Problem haben wir auch. 

Ich möchte gleich allen den Wind aus den Segeln nehmen, die 
gedacht haben, daß man einfach über den IntuiText, der in die 
Gadget-Struktur eingebunden werden kann, die Namen ausgibt. 
Dem möchte ich entgegenhalten, daß diese Methode ziemlich 
umständlich wird, wenn erst eine File-Liste vorhanden ist, die 
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mehr Namen enthält als in das Window passen. Dann müssen die 
Texte beim Scrollen immer wieder geändert werden. Dazu eignet 
sich diese Methode aber überhaupt nicht. Sie ist viel zu um¬ 
ständlich. 

Am besten wäre es, eine Routine damit zu beauftragen, die Liste 
der Namen, beginnend bei einem bestimmten Namen, in festge¬ 
legter Anzahl auszugeben. Vorher richten wir in diesem Feld die 
festgelegte Anzahl von Gadgets ein, die gar keine Grafik besit¬ 
zen. Nur durch den Klickbereich sind sie zu erkennen. Dieser 
darf natürlich nicht höher als eine Zeile, also 8 bzw. 9 Punkte, 
sein und muß die maximal zugelassene Zeichenzahl eines File- 
Namens umfassen. Da dies alles Boolean-Gadgets sind, können 
wir mit der einfachen Gadget-Struktur arbeiten: 

struct Gadget FileGadget = 

< 


NULL, 

/* NextGadget 

*/ 

80, 0, 

/* LeftEdge, TopEdge 

*/ 

200, 8, 

/* Width, Height 

*/ 

GAOGHCOMP, 

/* Flags 


RELVERIFY, 

/* Activation 

*/ 

BCX)LGADGET, 

/* Gadget Type 

*/ 

NULL, 

/* GadgetRender 

♦/ 

NULL, 

/* Select Render 

*/ 

NULL, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 

*/ 

NULL, 

/* SpecialInfo 

*/ 

0, 

/* Gadget10 

*/ 

NULL 

>; 

./* UserData 

*/ 


Struktur 3.13: FileGadget 

Wegen der großen Breite unserer Gadgets möchte ich Sie bitten, 
jetzt erneut das Standardprogramm 1 zu laden und dort die Win¬ 
dow-Struktur dahingehend zu ändern, daß das Window als Left- 
Edge 120 und als Width 360 hat. Wir wollen nämlich jetzt schon 
mit der Entwicklung einer File-Select-Box beginnen, und dazu 
brauchen wir ein so breites Window. Sehen Sie sich vielleicht 
schon mal die Entwurfszeichnung an: 
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EntHurf einer Pile-Select^Box als NindoH 



Proportional- 

Gadget 


Boolean 

Gadgets 


Abbildung 3.11: Entwurf: Aussehen File-Select-Box 


Wir brauchen also ein großes Feld für die File-Namen, einen 
Schiebebalken, den wir ja oben bereits programmiert haben, 
zwei String-Gadgets und drei Boolean-Gadgets. Nach diesem 
Abstecher zur Übersicht unseres Projektes kehren wir zurück zu 
den vielen Gadgets für das Selektieren eines Namens. 

Mit der ersten definierten Gadget-Struktur werden wir nicht 
weit kommen. Wir brauchen einiges mehr, doch jede Struktur 
einzeln zu definieren macht ja viel zu viel Arbeit. Erinnern wir 
uns deswegen an das Beispiel der IntuiText-Strukturen. Dort ha¬ 
ben wir auch eine Struktur mehrfach reproduziert. Das läßt sich 
hier genauso handhaben: 

Vor der Hauptfunktion definieren wir diese Gadget-Struktur 
und noch ein Feld mit noch nicht ausgefüllten Strukturen. 

struct Gadget Files[15]; 

Dazu brauchen wir dann im Programm eine Funktion, die die 
allgemeine Struktur dort hineinkopiert und gleichzeitig die Y- 
Position korrigiert. 
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Make_Files(Files) 
struct Gadget Struktur[]; 
i 

int i; 

for (1=0; i<15; i++) 

C 

Struktur Ci] = FileGadget; 

Struktur[i].TopEdge = 30 + i * 8; 
Struktur[i].GadgetID = i + 1; 

Struktur[i].NextGadget = ÄStruktur[i+1]; 
> 

Struktur[14].NextGadget = NULL; 

> 


Funktion 3.5: Make-File-Gadgets 


Dokumentation 

Die Funktion trägt in das Strukturenfeld jedesmal die allgemeine 
Struktur ein und korrigiert den Y-Wert (TopEdge). Außerdem 
linkt sie die gesamte Liste der 15 Gadgets zusammen, damit sie 
nachher durch einen einfachen Aufruf (AddGListO) in das Win¬ 
dow gebracht werden kann. Weiterhin bekommt jedes Gadget 
eine ID beginnend bei 1. Dadurch läßt sich später bei der Aus¬ 
wahl feststellen, welches der User-Gadgets angeklickt wurde. 
Ein Refresh ist in diesem Fall nicht nötig, da sowieso keine 
Grafik verwendet wird. 

Somit haben wir das erste Problem gelöst. 

Fügen Sie jetzt das oben definierte Proportional-Gadget mit in 
das Programm ein. Verändern Sie dazu die Variable LeftEdge 
auf den Wert 300. Außerdem muß die ID dieses Gadgets einen 
Wert größer als 15 erhalten, damit es von den anderen zu un¬ 
terscheiden ist. Ich schlage 20 vor, damit etwas Platz bleibt für 
Ergänzungen. 

Jetzt fehlen uns noch die beiden String-Gadgets. Da es nur zwei 
sind, können wir sie normal über die Strukturen definieren. 
Hierbei tritt der wunderbare Zustand ein, daß wir nur einen 
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Undo-Puffer benötigen, da immer nur ein Gadget zur Zeit aktiv 
sein kann. 

unsigned char OrdnerBuffer[512] = “dfl:”; 
unsigned char Datei Buffer [31] = 

unsigned char UndoBuffer [512]; 
struct StringInfo OrdnerInfo = 


C 


ÄOrdnerBuffer[0], 

/* Buffer 


ÄUndoBuffer[0], 

/* Undo Buffer 

*/ 

0, 

/* Buffer Position 

*/ 

511, 

/* MaxChars 


0, 

/* Display Positoin 

*/ 

0. 

/* Undo Position 

*/ 

0, 

/* NumChars 

*/ 

0, 

/* Display Counter 

*/ 

0. 0, 

/* CLeft, CTop 

*/ 

NULL, 

/♦ LayerPtr 


0. 

/* Longint 

*/ 

NULL 

>; 

/* AltKeyMap 

*/ 

Struct Stringinfo Datei Info = 

r 


V 

ÄDateiBuffer[0], 

/* Buffer 


ÄUndoBuffer[0], 

Undo Buffer 


0, 

/* Buffer Position 

*/ 

31, 

/* MaxChars 

*/ 

0, 

/♦ Display Position 

*/ 

0, 

/* Undo Position 

*/ 

0, 

/* NumChars 

*/ 

0, 

/* Display Counter 

*/ 

0, 0, 

/♦ CLeft, CTop 

*/ 

NULL, 

/* LayerPtr 


0, 

/* Longint 

*/ 

NULL 

/* AltKeyMap 



>; 

SHORT StringPairs [] = 

0, 0, 244, 0 

>; 

struct Border StringBorder = 

0, 10, 1, 0, JAM1, 2, StringPairs, NULL 

>; 

struct IntuiText OrdnerText = 

L 

1, 0, JAM2, -58, 1, NULL, (UBYTE *)'*Ordner:'' ,NULL 

>; 
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struct IntuiText DateiText = 

C 

1, 0, JAM2, -58, 1, NULL, (UBYTE *)»Datei ,NULL 

>; 


struct Gadget Ordner = 

C 

NULL, 

80, 160, 

245, 10, 

GADGHCOMP, 

RELVERIFY, 

STRGADGET, 

(APTR)&StringBorder, 

NULL, 

ÄOrdnerText, 

NULL, 

(APTR)&OrdnerInfo, 

21 , 

NULL 

>; 

struct Gadget Datei = 

C 

ÄOrdner, 

80, 160, 

245, 10, 

GADGHCOMP, 

RELVERIFY, 

STRGADGET, 

(APTR)&St ringBorder, 
NULL, 

ÄDateiText, 

NULL, 

(APTR)&DateiInfo, 

22 , 

NULL 

>; 


/* NextGadget */ 
/* LeftEdge, TopEdge */ 
/* Width, Height */ 
/* Flags */ 
/* Activation */ 
/* Gadget Type */ 
/* GadgetRender */ 
/* Select Render */ 
/* GadgetText */ 
/* MutualExclude */ 
/* SpecialInfo */ 
/* GadgetID ♦/ 
/* UserData */ 


/* NextGadget */ 
Z’*' LeftEdge, TopEdge */ 
Z"*" Width, Height V 
Z* Flags V 
Z* Activation *Z 
Z* Gadget Type *Z 
Z* GadgetRender *Z 
Z* Select Render V 
Z* GadgetText *Z 
Z* MutualExclude *Z 
Z* SpecialInfo *Z 
Z* GadgetID *Z 
Z* UserData *Z 


Struktur 3.14: String-Gadgets: Datei <fe Ordner 


Als letzte Gadgets für unsere File-Select-Box fehlen nur noch 
die Boolean-Gadgets. Hier ist es ganz einfach: Mit nur einer 
Border-Struktur, drei IntuiText-Strukturen und drei Gadget- 
Strukturen ist alles erledigt: 

SHORT SelectPairsC] = 

C 

0, 0, 60, 0, 60, 20, 0, 20, 0, 0 

>; 
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struct Borden SelectBorder = 

C 

-2, -2, 1, 0, JAM1, 5, SelectPairs, NULL 

>; 

struct IntuiText OKText = 

C 

1, 0, JAM2, 1, 5, NULL, (UBYTE *)•' OK “ ,NULL 

>; 

struct IntuiText AbbruchText = 

C 

1, 0, JAM2, 1, 5, NULL, (UBYTE *)''Abbruch» ,NULL 

>; 

struct IntuiText ZurueckText = 


C 

1, 0, JAM2, 1, 5, NULL, 

>; 

struct Gadget OK = 

C 

NULL, 

10, 40, 

60, 20, 

GADGHCOMP, 

RELVERIFY, 

BOOLGADGET, 
(APTR)&SelectBorder, 
NULL, 

&OKText, 

NULL, 

NULL, 

23, 

NULL 

>; 

struct Gadget Abbruch = 

C 

&OK, 

10, 65, 

60, 20, 

GADGHCOMP, 

RELVERIFY, 

BOOLGADGET, 
(APTR)&SelectBorder, 
NULL, 

ÄAbbruchText, 

NULL, 

NULL, 

24, 

NULL 

>; 


(UBYTE *)»2urück!»' ,NULL 


/* NextGadget 
/* LeftEdge, TopEdge */ 
I* Width, Height */ 

/* Flags V 

/* Activation */ 

/* Gadget Type */ 

/♦ GadgetRender */ 

/* Select Render */ 

/* GadgetText */ 

/* MutualExclude */ 

/* Special Info */ 

/* GadgetID */ 

/* UserData */ 


/* NextGadget */ 
/* LeftEdge, TopEdge */ 
/* Width, Height */ 
/* Flags */ 
/♦ Activation */ 
/* Gadget Type */ 
/* GadgetRender */ 
/* Select Render */ 
/* GadgetText */ 
/* MutualExclude */ 
/* Special Info */ 
/* GadgetID */ 
/* UserData */ 
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struct Gadget Zurueck = 

< 

&Abbruch, 

10, 90, 

60, 20, 

GADGHCOMP, 

RELVERIFY, 

BOOLGADGET, 

(APTR)&SelectBorder, 

NULL, 

&ZurueckText, 

NULL, 

NULL, 

25, 

NULL 

>; 


/* NextGadget */ 
/* LeftEdge, TopEdge */ 
l* Width, Height */ 
/* Flags */ 
/* Activation */ 
/* Gadget Type */ 
/* GadgetRender */ 
/* Select Render */ 
/* GadgetText */ 
/* MutualExclude */ 
/* SpecialInfo */ 
/* GadgetID */ 
/* UserData */ 


Struktur 3.15: Boolean-Gadgets: OK, Abbruch & Zurück 


Wir haben nun drei gelinkte Gadget-Listen: die File-Gadgets 
ohne Grafik^ die beiden String-Gadgets und die Boolean-Gad¬ 
gets. Außerdem haben wir noch ein Proportional-Gadget. Bauen 
Sie jetzt bitte alle Gadget-Definitionen in das Standardprogramm 
ein, und denken Sie an die Window-Ausmaße! Dann ergänzen 
wir im Hauptprogramm nach dem Funktionsaufruf Open_All(): 


Make_Files(Files); 

FilePos = AddGListCFirstwindow, Files, -IL, 15L, NULL); 
StrgPos = AddGListCFirstwindow, Datei, -1L, 2L, NULL); 
SlctPos = AddGListCFirstwindow, Zurueck, -1L, 3L, NULL); 
PropPos = AddGadgetCFirstwindow, Schieber, -1L); 

RefreshGListCDatei, FirstWindow, NULL, 2L); 
RefreshGListCZurück, FirstWindow, NULL, 3L); 

RefreshGListCSchieher, FirstWindow, NULL, 1L); 


Frogrammteil 3.6: Gadgets einbinden 

Die Gadget-Abfrage wollen wir jetzt noch nicht mit einer Aus¬ 
wertung beauftragen. Hier setzen wir einfach eine Ausgabe der 
GadgetID ein, falls es sich um ein selbstdefiniertes handelt. Die 
nötigen Programmteile finden Sie dazu im Beispiel ’Toggle-Gad- 
get zum Auschalten”. 
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Es fehlt lediglich noch die Zeile: 

printfC'Gadget-Nummer: %d\n“, GadgetNr); 


3.4.2.2 Das neue Sizing-Gadget 

Nun kommen wir endlich zum neuen Sizing-Gadget. Hier noch 
einmal eine kurze Funktionsbeschreibung: Das Gadget wird in 
den Window-Rand eingebaut. Wird es dort angeklickt und hat 
das Window nicht die maximale Größe, die es beim Screen an¬ 
nehmen kann, wird es vergrößert. Hat es die maximale Größe 
im Screen, wird es bei erneutem Anklicken auf sein Minimum 
gebracht. Achten Sie dafür darauf, daß die MinWidth- und 
MinHeight-y/erte initialisiert sind. 

struct Gadget Sizing ~ 
i 


NULL, 

/* NextGadget 

*/ 

-10, 15, 

/* LeftEdge, TopEdge 

*/ 

8, 10, 

/* Width, Height 

*/ 

GADGHCOMP j 

/* Flags 

*/ 

GRELRIGHT, 

RELVERIFY | 

/* Activation 

*/ 

RIGHTBORDER, 

BOOLGADGET, 

/* Gadget Type 

♦/ 

(APTR)&SizingImage. 

/* GadgetRender 

*/ 

NULL, 

/* Select Render 

*/ 

NULL, 

/* GadgetText 

*/ 

NULL, 

/* MutualExclude 

*/ 

NULL, 

/* SpecialInfo 

*/ 

0, 

/* Gadget10 

*/ 

NULL 

/* UserData 

*/ 


>; 


Struktur 3.16: Sizing-Gadgets 


Als Image-Struktur übernehmen Sie bitte die, die wir am Ende 
des letzten Kapitels dafür erarbeitet haben. Die Abfrageroutine 
sollte dann folgende Arbeiten vornehmen: 

SizingO 

C 

SHORT ScreenWidth, ScreenHeight; 

ScreenWidth = Window->WScreen->Width; 
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ScreenHeitgh= Window->WScreen“>Height; 

if (Window->LeftEdge == NULL & Window->TopEdge == NULL) 
if (Window->Width == ScreenWidth & 

Window->Height == ScreenHeight) 
SizeWindow(Window, -1*(Window->Width - Window->MinWidth), 
-1*(Window->Height - Window->MinHeight); 


> 


MoveWindow(Window, -1*Window->LeftEdge, -1*Window->TopEdge); 
Si 2 eWindow(Window, ScreenWidth - Window->Width, ScreenHeight - 

Window->Height); 


Funktion 3.6: Size-Window 


3.5 Requester: Viele Informationen auf einmal 

Requester stellen eine Weiterentwicklung der Gadgets dar. Gad- 
gets sind in erster Linie dafür gedacht, während des Programm¬ 
ablaufs Informationen und Anweisungen zu sammeln. 

Es kommt manchmal vor, daß das Programm ganz dringend eine 
Entscheidung oder Information benötigt. In diesem Fall kann das 
Programm nicht so lange warten, bis irgendwann einmal die er¬ 
wartete Information geliefert wird. Hierfür muß der Benutzer 
"erpreßt" werden, die Entscheidung zu fällen, damit das Pro¬ 
gramm Weiterarbeiten kann. Unter "erpressen" hat man zu ver¬ 
stehen, daß es so lange nicht mehr erlaubt ist, in der Arbeit 
fortzufahren, bis die Nachfrage beantwortet ist. 

In diesem Fall tritt ein Requester in Erscheinung. Das ist eine 
Ansammlung von Gadgets (mindestens eins), die bei der Beant¬ 
wortung der Frage helfen. Natürlich können zu den Gadgets 
noch Texte treten, die das Problem oder die Frage näher erläu¬ 
tern. Es ist sogar möglich, ganze Grafiken in den Requester 
einzubauen. 

Das einfachste Beispiel sind die System-Requester. Sie erschei¬ 
nen, z.B. sobald irgendeine Diskette eingelegt werden muß. Bis 
Sie entweder das Einlegen verweigert haben oder Sie die Dis¬ 
kette tatsächlich einlegen, ist das Weiterarbeiten auf der Work- 
bench blockiert. Ein großer Vorteil der Requester ist, daß nicht 
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nur durch Anklicken eines Requester-Gadgets weitergearbeitet 
werden kann, sondern auch durch Einlegen einer Diskette. Es 
sind also mehrere Eingabewege offen. 

Das File-Select-Box-Window, das wir im vorhergehenden Kapi¬ 
tel zusammengebaut haben, wollen wir an dieser Stelle in einen 
Requester umbauen. Dieser dient als Nachfrage für die Anwei¬ 
sung, daß ein File geladen oder gespeichert werden soll. Wir 
benötigen aber ebenfalls die Information, wie das File heißt und 
in welchem Verzeichnis es liegt. 

Zuvor werden wir uns langsam mit der Materie beschäftigen und 
uns dazu die einfachen, von Intuition größtenteils unterstützten 
Requester ansehen. Damit kann man schon einiges machen, und 
die Programmierung ist wesentlich einfacher. 

Ich wünsche viel Spaß bei der Requester-Programmierung! 


3.5.1 Der Automatik-Requester 

Wie schon erwähnt, sind Requester eine Verknüpfung mehrerer 
Gadgets. Allerdings haben Sie bestimmt auch schon die Erfah¬ 
rung gemacht, daß die Gadget-Programmierung zwar einfach, 
aber dafür doch ziemlich schreibaufwendig ist. Wir kommen 
selten mit nur einer Struktur aus, denn ohne Grafik läuft hier 
nicht viel. 

Intuition bietet als einfache Lösung für dieses Problem den Au¬ 
tomatik-Requester an. Das ist ein Requester, der immer aus zwei 
Gadgets und einem erläuternden Text besteht. Die einfachen 
Anfragen lassen sich damit leicht lösen und erfordern keine 
aufwendige Programmierung. Der besondere Vorteil des Auto- 
matik-Requesters ist, daß es dafür nicht einer eigenen Struktur 
bedarf. Wir übergeben der Funktion einfach die Zeiger auf die 
IntuiText-Strukturen und bekommen einen Wert zurück, wenn 
der Requester beantwortet wurde. 
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Für die Arbeit mit unserem Automatik-Requester benötigen wir 
erst einmal einen Zeiger auf ein Fenster. Dieser muß aber nicht 
unbedingt initialisiert sein. 

Als nächstes können drei IntuiText-Strukturen angegeben wer¬ 
den. Die erste steht für einen allgemeinen Text, der am besten 
zur Erläuterung des Problems verwendet wird. Meistens steht 
hier eine Frage oder Anweisung. Die anderen beiden Texte sind 
für zwei Gadgets vorgesehen. Sie kennen das sicherlich von den 
System-Requestern. In der linken Ecke steht der "PositiveText", 
der ein Zustimmen oder ein Bestätigen kennzeichnen sollte. Der 
dritte Text stellt genau das Gegenteil dar und wird in der rech¬ 
ten Ecke unseres Requesters ausgegeben. Nehmen Sie hier einen 
Text, der verneint, abbricht oder ablehnt. 

Jetzt fehlen uns noch zwei Flags. Das erste steht für den auslö¬ 
senden Faktor des zustimmenden Gadgets. Sie können dieses 
Flag auf Null setzen, denn das Anklicken des Gadgets ist immer 
auslösender Bestandteil. Das zweite Flag erfüllt genau die gleiche 
Aufgabe wie das erste, allerdings in bezug auf das ablehnende 
Gadget. Die letzten beiden Werte kommen Ihnen sicherlich be¬ 
kannt vor. Da Intuition nicht weiß, welche Ausmaße der Text 
und die Gadgets haben werden, können Sie an dieser Stelle die 
Größe des Requesters festlegen. Über die Größe der Umrandung 
unserer Gadget-Texte brauchen Sie sich überhaupt keine Gedan¬ 
ken zu machen, Intuition berechnet anhand des Textes selbstän¬ 
dig die Ausmaße. 

Hier haben Sie das allgemeine Format unserer neuen Funktion 
mit allen Parametern in einer Kurzbeschreibung; 

Response = AutoRequest(Window, BodyText, PositiveText, 

DO -348 AO A1 A2 

NegativeText, PositiveFlags, Negativerlags, 
A3 DO Dl 

Uidth, Height); 

D2 D3 
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Parameter 

Window 

BodyText 

PositiveText 

NegativeText 

PositiveFlags 

NegativeFlags 

Uidth 

Height 


Zeiger auf eine Window-Struktur. 

IntuiText-Struktur für den allgemeinen Text. 
IntuiText des Ja-Feldes. 

IntuiText des Nein-Feldes. 

IDCMP-Flag für das Ja-Feld. 

IDGMP-Flag für das Nein-Feld. 

Breite des Auto-Requester-Windows. 

Höhe des Auto-Requester-Windows. 


Das Beispiel für den Requester benötigt nicht einmal das Stan¬ 
dardprogramm. Wir initialisieren einfach die IntuiText-Struktu- 
ren und übergeben alle Werte der Funktion. Von dieser erhalten 
wir nach Beantwortung durch den Benutzer den Wahrheitswert 
zurück. Nach dessen Auswertung können wir im DOS-Fenster 
einen entsprechenden Text ausgeben. Das folgende Programm 
erledigt diese Arbeit für uns: 


* * 


* Programm; AutoRequester 


* sssssrsss 


* 

* Autor: 


Datum: 


Kommentar: * 


Wgb 


27.12.1987 


*****************************w****^ 


#include <exec/types.h> 

#include < i ntuition/intu 1 1 1 on.h> 


struct IntuitionBase *IntuitionBase; 
struct Window ^Window = NULL; 


struct IntuiText Body = 

< 

0 , 1 , 

JAM2, 

10 , 10 , 

NULL, 

(UBYTE *)''WoUen Sie Requester Programmieren?*', 
NULL 
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>; 


struct IntuiText JA = 
i 

2. 3, 

JAM2, 

5, 3, 

NULL, 

(UBYTE * *)" Ich will m«, 
NULL 
>; 

struct IntuiText NEIN s 
i 

2, 3, 

JAM2, 

5. 3. 

NULL, 

(UBYTE *)" BIOS nicht 111", 
NULL 
>; 


mainO 

( 

B(X)L Antwort; 

Open_All(); 

Antwort = AutoRequest(Uindow, &Body, &JA, 

&NEIN, OL, OL, 320L, 60L); 


if (Antwort « TRUE) 

printfC'Wer's glaubt, wird selig!\n''}; 
eise 

printfC'Oie Warheit ist inner am besten.\n"); 

Close AIK); 

> 


^********************************** 
* * 

* Funktion: Library öffnen 

* sssssssssssssssssssssssss 

* 

* Autor: 

* _ 


Wgb 


Datum: 

16.10.1987 


* 

* 

Kommentar: * 

_ * 

* 

* 

* 
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Open_AlU) 

< 

vo 1 d *OpenLibra ry(); 

if (!(IntuitionBase = (struct IntuitionBase *) 
OpenL 1 brary(“intuition.library“, OL))) 

C 

printf("Keine Intuition Library gefunden!\n"); 

Close_All(); 

exit(FALSE); 

> 

> 


y*************************************** 

* * 

* Funktion: Alles Geöffnete schließen * 

* * 

* Autor: Datum: Kommentar: * 

4r ...... .......... .......... * 

* Ugb 16.10.1987 Intuition ♦ 

* * 

* * 

***************************************y 


Ctose Allo 
{ ” 

if (IntuitionBase) CloseLibrary(IntuitionBase); 
> 


Programm 3.6: Auto-Requester 


Dokumentation 

Das Besondere an diesem Programm ist, daß wir einen System- 
Request auch ausgeben können, wenn wir kein Bezugs-Window 
haben. Dies ist z.B. wichtig bei der Aufforderung, Speicher frei 
zu machen, wenn es nicht möglich ist, das Ausgabe-Window zu 
öffnen. Dafür setzen wir den Window-Pointer auf Null. Denken 
Sie daran, daß dies zwar bei jeder Requester-Funktion möglich 
ist, aber dem Zweck wenig dienlich ist. Wir wollen schließlich 
die Eingabe umleiten. 

Ein besonderer Vorteil ist es, daß AutoRequester darüber hinaus 
nicht nur über die Maus beantwortet werden können. Auch das 
Einlegen einer Diskette kann die Antwort für eine der beiden 
Entscheidungen sein. Der Requester läßt sich auch über die Ta- 
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Statur beantworten. Ein besonderer Komfort! Für das "Retry"- 
Feld kann auch die rechte Amiga-Taste mit V gedrückt werden, 
das "Cancel"-Feld können Sie durch Amiga-B simulieren. Ein¬ 
facher geht es nun wirklich nicht! 

Der einzige minimale Nachteil der Auto-Requester liegt im 
Window. Wir können keine Eigenschaft des Requester-Windows 
bestimmen und sind deshalb auf die Überschrift, die Gadgets 
und auch die Ausmaße angewiesen. Darüber kann man ange¬ 
sichts der einfachen Programmierung hinwegsehen. 


3.5.2 Der System-Requester 

Die Bedienung und Programmierung des Auto-Requesters ist 
sehr einfach. Einziger Nachteil: Es besteht keine Möglichkeit des 
Eingriffs in den Aufbau. 

Deshalb hat man es ermöglicht, einen Teil der AutoRequest- 
Routine zu nutzen, um dann alles Restliche selber zu verändern. 
Diese Routine heißt BuildSysRequest() und ist eine Unterroutine 
von AutoRequest(). Die folgenden Voraussetzungen müssen wir 
erfüllen, damit wir mit BuildSysRequest() arbeiten können: 

Zuerst muß ein Window geöffnet werden, das sich nach der 
Größe der Texte richten sollte. Dann übergeben wir wie üblich 
den Text für eine allgemeine Beschreibung und die Texte für 
die beiden Gadgets. Außerdem benötigen wir noch das IDCMP- 
Flag für das Requester-Window und als letztes die Größe des 
Requesters. 

Mit diesen Parametern läßt die Routine nun einen Requester 
entstehen. Dieser wird im Stil dem AutoRequest gleichen: der 
Body-Text im oberen Teil des Requesters, in der unteren rech¬ 
ten und linken Ecke je ein Gadget mit den beiden anderen 
Texten. Als Kommunikationskanal bekommen wir den Zeiger 
auf das Requester-Window zurück. Entweder ist dies der Zeiger, 
den wir übergeben haben, oder aber wir haben Null übergeben, 
und die Routine hat selbständig auf der Workbench ein Fenster 
geöffnet. 
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Die Abfrageroutine für den neuen Requester müssen wir aller¬ 
dings selbst schreiben. Dabei können alle IDCMP-Möglichkeiten 
genutzt werden. Es ist dabei unerheblich, ob Tastatureingabe 
oder Mausabfrage gewünscht wird. Alle Eingaben sind erlaubt. 

Wenn die Routine Probleme beim öffnen des Requesters hat, 
wird dieser Requester wie auch ein AutoRequest in eine reco- 
verable Alert umgewandelt. Dann liefert BuildSysRequest() nicht 
den Zeiger auf ein Window zurück, sondern einen Wahrheits¬ 
wert, mit dem wir erfahren, welche der beiden Antworten ge¬ 
wählt wurde. 


Vor weiteren Beschreibungen sollen Sie erst das Format dieser 
Funktion kennenlernen: 


ReqUindou = BuiIdSysRequest(Window, BodyText, PositiveText, 
DO *360 AO AI A2 


NegativeText, IDCMPFlags, Width, Height); 
A3 DO D2 D3 


struct Window 
struct Window 
struct IntuiText 
struct IntuiText 
struct IntuiText 
ULONG IDCMPFlags; 
SHORT Width, Height; 


♦ReqWindow; 

*Window; 

♦BodyText; 

♦PositiveText; 

♦NegativeText; 


Für die Abfrageroutine, die Sie eigenhändig schreiben müssen, 
brauchen Sie noch einige Informationen über die Gadgets. Bei 
jedem Gadget sind die folgenden Gadget-Flags gesetzt: 


BOOLGADGET, RELVERIFY, REQGADGET und TOGGLESELECT 

Die Gadgets sollten in Ihrem Interesse mit dem gleichen Ausse¬ 
hen versehen werden, wie es allgemein üblich ist. Dafür stehen 
die AUTO-Flags im <intuition/intuition.h>-Include-File zur 
Verfügung: 



366 


Das große C-Buch zum Amiga 


Auto-Name 

Wert 

Beschreibung 

AUTCX)RAWMODE 

JAM2 

Hintergrund- und Vordergrundfarbe 

AUTOFRONTPEN 

OL 

Zeichenfarbe 1 

AUTOBACKPEN 

IL 

Zeichenfarbe 2 

AUTOLEFTEDGE 

6L 

Positionen des Intui-Textes 

AUTOTOPEDGE 

3L 


AUTOITEXTFONT 

NULL 

Zeichensatz für Texte: Workbench-Zs. 

AUTONEXTTEXT 

NULL 

Zeiger auf weitere Texte 


Tabelle 3.13: A UTO-Konventionen 


Alle Flags können in den IntuiText-Strukturen verwendet wer¬ 
den, damit eine einheitliche Gestaltung gewährleistet ist. Sie 
sollten das beachten, denn der Benutzer würde einfach überfor¬ 
dert werden, wenn er sich ständig andere Konventionen merken 
müßte. 

Mit dieser Beschreibung sollte es Ihnen möglich sein, einen Sy- 
stem-Requester zu öffnen. Allerdings fehlt noch die Reaktion 
beim Schließen des Requesters. Diese wird gebraucht, um alle 
Strukturen und jeden Speicher, der für die Arbeit gebraucht 
wurde, wieder freizugeben. Diese Aufgabe übernimmt die 
Funktion FreeSysRequest(). Ihr übergeben Sie einfach den Zei¬ 
ger, den die BuildSysRequest()-Routine zurückgeliefert hatte. 
Wurde nur ein Wahrheitswert ausgegeben, weil kein Speicher für 
einen Requester vorhanden war, darf diese Funktion nicht auf- 
gerufen werden. 


3.5.3 Wir bauen uns den Requester selbst 

Nicht immer kommt man mit den Möglichkeiten des Auto-Re- 
questers weiter. In vielen Fällen bietet er einfach zu wenig mit 
seinem Ja/Nein-Rückgabewert. Dann tritt der CustomRequester 
in Aktion! 
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Für einen CustomRequester braucht das System wieder so viele 
Angaben, daß es sich lohnt, dafür eine Struktur einzurichten. 
Diese Struktur enthält alle Informationen über Art, Umfang und 
Aussehen des Requesters. Allerdings wird der Vorteil der Flexi¬ 
bilität durch die Handhabung wieder ausgeglichen. Wir müssen 
eine Abfrage programmieren, denn hier kann uns das System bei 
den vielen verschiedenen Bedürfnissen nicht weiterhelfen. 

Sehen Sie einen CustomRequester wie ein Window, in dem wir 
viele Gadgets zu einem Thema untergebracht haben. Mindestens 
ein Gadget teilt dem Programm durch Auslösen irgendwann mit, 
daß die Eingabe beendet wurde. Danach können wir die gewon¬ 
nenen Daten auswerten. Ein Request ist natürlich nur eine Flä¬ 
che in einem Window, meistens wird aber extra ein neues geöff¬ 
net, das alleine für den Requester benutzt wird. So hat der Be¬ 
nutzer optimale Bedienungsmöglichkeiten. 


3.5.3.1 Oie Requester-Struktur 

Für jeden Requester brauchen wir eine Requester-Struktur. Sie 
enthält ähnliche Informationen wie die Window-Struktur: 


struct Requester 

f 

0x00 

00 

struct Requester *OlderRequest; 

0x04 

04 

SHORT LeftEdge; 

0x06 

06 

SHORT TopEdge; 

0x08 

08 

SHORT Width; 

OxOA 

10 

SHORT Height; 

OxOC 

12 

SHORT RelLeft; 

OxOE 

14 

SHORT RelTop; 

0x10 

16 

struct Gadget *ReqGadget; 

0x14 

20 

struct Border *ReqBorder; 

0x18 

24 

struct IntuiText ‘RegText; 

0x1 C 

28 

USHORT Flags; 

OxIE 

30 

UBYTE BackFUl; 

0x20 

32 

struct Layer *ReqLayer; 

0x24 

36 

UBYTE ReqPadl[32]; 

0x44 

68 

struct BitMap *IinageBMap; 

0x48 

72 

struct Uindou *RUindou; 

0x4C 

76 

UBYTE ReqPad2[36]; 

0x70 

>; 

112 
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Die Variable OlderRequester brauchen wir nicht zu initialisieren, 
denn sie wird von Intuition nur zu Verwaltungszwecken genutzt. 

LeftEdge, TopEdge, Width und Height geben die Position und 
Größe des Requesters im Window an. 

Mit RelLeft und RelTop läßt sich eine ganz nützliche Funktion 
unterstützen. Setzen Sie dazu im Flags-Wert das Flag POINT- 
REL! Dann wird der Requester nicht mehr an der unter Left¬ 
Edge und TopEdge angegebenen Position ausgegeben, sondern 
relativ zur Maus-Cursor-Position. Sie können damit erreichen, 
den Requester so zu positionieren, daß ein bestimmtes Gadget 
gleich unter dem Maus-Cursor liegt. 

Die nächsten drei Pointer sind in die Struktur übernommen, da¬ 
mit Sie Gadgets, Border und Texte verwenden können. Ohne die 
Gadgets könnte natürlich der ganze Requester nicht bestehen. 
Border wurde implementiert, damit Sie dem Requester einen 
"schönen" Rand geben können, und mit IntuiText ist es möglich, 
noch einen erläuternden Text auszugeben. 

Der wichtigste Wert der Struktur, Flags, ist wieder ein Flag. Wie 
Sie oben unter RelLeft, RelTop erfahren haben, können Sie hier 
das Flag POINTREL setzen, damit der Requester relativ zur 
Maus-Cursor-Position ausgegeben wird. Es existiert aber noch 
ein zweites Flag. Mit PREDRAWN signalisieren Sie, daß alle 
Border-, IntuiText- und Image-Strukturen nicht beachtet wer¬ 
den sollen. Die ganze Grafik wird über die Variable ImageBMap 
geholt. Intuition sucht nach einer initialisierten und mit Grafik 
gefüllten BitMap. Achten Sie darauf, daß diese neue Grafik 
auch mit den Klickbereichen der Gadgets übereinstimmt, denn 
diese haben nun keine eigene Grafik mehr! 

In diesem Wert setzt Intuition auch eigene Flags. Es sind dies 
REQOFFWINDOW, was bedeutet, daß sich der Requester außer¬ 
halb des Bezugs-Windows befindet, und REQACTIVE, wenn der 
Requester gerade aktiv ist. Das Flag SYSREQUEST wird gesetzt, 
wenn es sich um einen System-Requester handelt (siehe dazu 
AutoRequest und SystemRequest). 
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Als nächste Variable steht BackFill in der Struktur. Hier findet 
man die Nummer des Zeichenstiftes, mit dem der Hintergrund 
des Requesters gefüllt werden soll. 

ReqLayer wird von Intuition gefüllt und enthält dann einen Zei¬ 
ger auf den Layer, der den Requester beinhaltet. 

ImageBMap ist ein Zeiger, der auf eine BitMap zeigen kann. 

RWindow ist eine Variable, die von Intuition verwaltet wird und 
auf die Window-Struktur zeigt, in dem der Requester unterge¬ 
bracht worden ist. 


3.5.3.2 Eine Requester-Struktur einrichten 

Da es nicht so einfach ist, für einen Requester genügend Gad- 
gets zusammenzutragen, wollen wir uns mit einem Beispiel hel¬ 
fen, das Sie auf jeden Fall in Ihre eigenen Programme einbauen 
können. (Dann lohnt sich auch die Arbeit!) Wir werden die File- 
Select-Box zu diesem Zweck in einen Requester Umrüsten. Da¬ 
mit wird die Handhabung im Programm wesentlich einfacher 
und strukturierter. Außerdem brauchen wir sowieso eine File- 
Select-Box für den Editor, unser Großprojekt. 

struct Requester FileSelectBox; 

InitRequest(&FileSelectBox); 

FileSelectBox.LeftEdge > 2; 

FileSelectBox.TopEdge = 10; 

FileSelectBox.Uidth » 360; 

FileSelectBox.Height = 200; 

FileSelectBox.ReqGadget= &Zurueck; 

Programmteü 3.7: Requester-Definiäon: FUe-Select-Box 

Strukturbeschreibung 

Die Ausmaße des Requesters sind denen des Windows angepaßt, 
das vorher für die File-Select-Box verwendet wurde. Durch die 
Funktion InitRequestO werden zuerst alle Parameter auf NULL 
gesetzt. Dann ergänzen wir unsere Werte. Der Gadget-Wert zeigt 



370 


Das große C-Buch zum Amiga 


auf das erste Gadget und führt sich weiter am NextGadget- 
Pointer jeder Struktur. Dafür müssen Sie die vier schon ge¬ 
schaffenen Gadget-Blöcke auch noch linken. Weil in jedem 
Gadget eines Requesters auch noch das REQGADGET-Flag ge¬ 
setzt werden muß, habe ich zur Verdeutlichung alle gelinkten 
Gadgets hier noch einmal aufgeführt: 

unsigned char OrdnerBufferC512] = **df1:**; 
unsigned char DateiBufferC31] = **"; 
unsigned char UndoBuffer [512]; 

USHORT KnobGrafikn - 




OxCCCC, 

0x6666, 

0x3333, 

0x9999, 

OxCCCC, 

0x6666, 

0x3333, 

0x9999, 

OxCCCC, 

0x6666, 

0x3333, 

0x9999, 

OxCCCC, 

>; 

0x6666, 

0x3333, 

0x9999 

struct Image 

Knob = 




i 


0, 0, 16, 16, 1, ÄKnobGrafikCO], 1, 0, NULL 

>; 


struct Proplnfo SchieberProp = 
i 

FREEVERT, 

0x8000, 0x8000, 

0x0800, 0x1000, 

0 , 0 , 

0 , 0 , 

0 , 0 


struct StringInfo OrdnerInfo = 

L 

ÄOrdnerBuffer[0], ÄUndoBuffer[0], 

5, 511, 0, 0, 0, 0, 0, 0, NULL, 0, NULL 

>; 

struct Stringinfo Datei Info = 
i 

&OateiBuffer[0], &UndoBuffer [0], 

0, 31, 0, 0, 0, 0, 0, 0, NULL, 0, NULL 

>; 

SHORT StringPairsC] = 
i 

0, 0, 248, 0 

>; 



Intuition und C für Fortgeschrittene 


371 


SHORT SelectPairsC] = 

t 

0, 0, 61, 0, 61, 21, 0, 21, 0, 0, 

>; 

struct Borden Stn'ngBorder = 

i 

0, 9, 1, 0, JAM1, 2, StringPairs, NULL 

>; 

struct Borden SelectBorder = 

L 

-1, -1, 1, 0, JAM1, 5, SelectPairs, NULL 

>; 

struct IntuiText OrdnerText = 

i 

1, 0, JAM2, -58, 1, NULL, (UBYTE *)"Ordner:*' ,NULL 

>; 


struct IntuiText Datei Text = 

i 

1, 0, JAM2, -58, 1, NULL, (UBYTE ♦)**Datei ,NULL 

>; 

struct IntuiText OKText = 

i 

1, 0, JAM2, 22, 5, NULL, (UBYTE *)"OIC*' ,NULL 

>; 

struct IntuiText AbbruchText = 

i 

1, 0, JAM2, 2, 5, NULL, (UBYTE *)**Abbruch” ,NULL 

>; 

struct IntuiText ZurueckText = 

L 

1, 0, JAM2, 2, 5, NULL, (UBYTE ♦)”Zurück!*' ,NULL 

>; 

struct Gadget Files[15]; 
struct Gadget FileGadget = 
i 

NULL, 

80, 0, 240, 8, 

GADGHCOMP, RELVERIFY, BOOLGADGET j REQGADGET, 

NULL, NULL, NULL, 

NULL, NULL, 0, NULL 

>; 

struct Gadget Schieber = 

i 

ÄFiles[0], 
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322, 30, 24, 120, 

GADGHNONE j GADGIMAGE, RELVERIFY, PROPGADGET 
(APTR)&Knob, NULL, NULL, 

NULL, (APTR)&SchieberProp, 1, NULL 

>; 

struct Gadget Ordner = 
i 

&Schieber, 

80, 165, 250, 8, 

GADGHCOMP, RELVERIFY, STRGADGET | REQGADGET, 
(APTR)&StringBorder, NULL, ÄOrdnerText, 

NULL, (APTR)&OrdnerInfo, 21, NULL 

>; 

struct Gadget Datei = 

C 

ÄOrdner, 

80, 180, 250, 8, 

GADGHCOMP, RELVERIFY, STRGADGET | REQGADGET, 
(APTR)&StringBorder, NULL, &DateiText, 

NULL, (APTR)&DateiInfo, 22, NULL 

>; 

struct Gadget OK = 
i 

&Oatei, 

10, 40, 60, 20, 

GADGHCOMP, RELVERIFY | ENDGADGET, BOOLGADGET 
(APTR)&SelectBorder, NULL, ÄOKText, 

NULL, NULL, 23, NULL 

>; 

struct Gadget Abbruch = 
i 

1o'^*65, 60, 20, 

GADGHCOMP, RELVERIFY | ENDGADGET, BOOLGADGET 
(APTR)&SelectBorder, NULL, SAbbruchText, 

NULL, NULL, 24, NULL 

>; 

Struct Gadget Zurueck = 
i 

&Abbruch, 

10, 90, 60, 20, 

GADGHCOMP, RELVERIFY, BOOLGADGET | REQGADGET, 
(APTR)&SelectBorder, NULL, ÄZurueckText, 

NULL, NULL, 25, NULL 

>; 


REQGADGET, 


REQGADGET, 


I REQGADGET, 


Struktur 3.16: Alle Requester-Gadgets 
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3.5.3.3 Die Requester-Funktionen 

Ausgehend von den oben abgedruckten Gadgets und der Reque- 
ster-Struktur möchte ich ein Programm mit Ihnen entwickeln, 
das es ermöglicht, jedes eigene Programm dahingehend zu er¬ 
gänzen, daß Sie auch die File-Select-Box benutzen können. 


Wir brauchen dazu unser Standardprogramm 1. Definieren Sie 
die NewWindow-Struktur wie abgedruckt und global auch die 
Requester-Struktur. Vorher müssen noch die Gadgets mit ihrem 
"Anhang" eingefügt werden. Jetzt kann das Programm beim Ab¬ 
laufen darauf warten, einen Anstoß zu bekommen, daß es den 
Requester aktivieren soll. Wir aktivieren ihn sofort. Sie können 
später eine Bedingung dafür einsetzen, wie z.B. die Auswahl ei¬ 
nes Menüpunktes. 


struct NewUindow FirstNewUirxlow = 

I* LeftEdge, TopEdge */ 
I* Uidth, Height V 
/* DetailPen, BlockPen V 
/* IDCMP Flags V 


160, 30, 

370, 220, 

0 , 1 , 

CLOSEUINDOU j 
GADGETUP I 
REQCLEAR, 

WINDOUDEPTH j 
WINDOUSIZING I 
WINDOWDRAG | 

UINDOWCLOSE j 
SMARTEREFRESH, 

NULL, 

NULL, 

(UBYTE ♦)"Requester Test 
NULL, 

NULL, 

100, 50, 

640, 256, 

WBENCHSCREEN 

>; 


/* Flags V 


/* First Gadget 
/♦ CheckMark */ 

/* Screen */ 
/♦ BitMap V 
i* Min Uidth, Height V 
/♦ Max Uidth, Height */ 
/* Type */ 


Struktur 3.17: NewWindow-Struktur ßr den Requester 


Zum Aufrufen des Requesters benutzen wir die einfache Intui¬ 
tion-Funktion Request(). Sie verlangt nur zwei Parameter. Hier 
ist das allgemeine Format und die Zeile für unser Programm: 
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Success = Request(Requester, Window); 
DO -240 AO AI 


Request(&FileSelectBox, FirstUindow); 

Nach diesem Aufruf ist die Datenleitung für die Eingabe des 
Windows blockiert. Wir empfangen darüber nur noch Signale 
vom Requester (wenn überhaupt). Das beste ist, man schreibt 
sich für die Behandlung der Requester-Eingabe eine Unterrou¬ 
tine. So gestalten wir das Programm übersichtlicher. Rufen wir 
die Routine gleich nach der Aktivierung so auf: 

FileSelectBox_Request(); 

In der Routine selbst fragen wir die Datenleitung wie schon be¬ 
kannt ab. Hinzu kommt, daß wir auf das Flag REQCLEAR 
achten müssen. Es kennzeichnet, daß der Benutzer die Eingabe 
beendet hat und wieder in den normalen Programmverlauf zu¬ 
rückkehren möchte. Das Signal wird von allen Gadgets ausgelöst, 
die unter Activation das Flag ENDGADGET gesetzt haben. Dies 
sind in unserem Fall die Boolean-Gadgets "ABBRUCH" und 
"OK". 


y*4r****4r*****4r**4r*4r*******4r*4r4r*iA*****Ar4r4r 

* Ar 

* Funktion: Request-Abfrage * 

* =================================== * 

* * 

* Autor: Datum: Kommentar: * 

Ar_ _ _ Ar 

* Wgb 28.12.1987 * 

Ar Ar 

Ar * 

ArArAr*ArAr*ArAr*ArAr*ArAr*ArArArArArArArArArArArArArArAr*ArArAr**ArAry 


FileSelectBox Request() 

BOOL Warten = TRUE; 

ULONG MessageClass; 

struct IntuiMessage *message; 
struct Gadget *GadgetPtr; 

USHORT GadgetID; 

while (Warten) 

if ((message - (struct IntuiMessage *) 
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GetMsg(FirstWindow->UserPort)) == NULL) 
i 

WaitdL « FirstWindow->UserPort->mp_SigBit); 

printf("SIGNAL!\n"); 

continue; 

> 

HessageClass = message’>Class; 

GadgetPtr = (struct Gadget *) iiiessage->IAddress; 
GadgetID = GadgetPtr‘>GadgetID; 
ReplyHsg(message); 

if (HessageClass REQCLEAR) 
i 

Warten = FALSE; 
continue; 

> 

if (HessageClass == GADGETUP) 
switch (GadgetID) 
i 

case SCHIEBER : printf("Schieher\n”); 
break; 

case ORDNER : printf("Ordner\n“); 
break; 

case DATEI : printf("DateiXn”); 
break; 

case ZURUECK : printf C'ZurückXn”); 
break; 


> 

if (GadgetID <= 16 && 1 <= cldgetlO) 

{ 

/* Tabellenabfrage V 
printf("Gadget-Nr. Xd\n", GadgetID); 
> 


> 


> 


Funktion 3.6: File-Select-Box Requester-Behandlung 


3.5.4 Requester: wann es der Benutzer will 

Selbst über den Service haben sich die Entwickler von Intuition 
Gedanken gemacht. Die Service-Eigenschaften werden durch die 
Möglichkeit eines Double-Menu-Requesters wesentlich gestei- 
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gert. Mit diesem Requester-Typ kann der Benutzer einen Re- 
quester aufrufen, wann immer er seine Funktionen nutzen will. 
Der Aufruf geschieht durch einen doppelten Druck auf die 
Menütaste der Maus. 

Jedesmal, wenn der Programmbenutzer zweimal auf die rechte 
Maustaste drückt - das muß in einem Zeitintervall von einem 
Doppelklick liegen - wird ein DMRequest ausgelöst. Diesen Re- 
quester können Sie mit SetDMRequest() für ein Window akti¬ 
vieren, Wenn der Requester angefordert wird, erhält das Pro¬ 
gramm eine Nachricht über den IDCMP, daß der erste Requester 
aktiviert wurde. Es kann dann zu einer speziellen Abfrage¬ 
schleife verzweigt werden. Hier erfolgt die Behandlung wie bei 
jedem anderen Requester. Wenn das Programm nicht mehr die 
Möglichkeit eines DMRequest anbieten will, kann es mit Clear- 
DMRequestO alles rückgängig machen. 

Ein Programm gilt als besonders bedienungsfreundlich, wenn es 
einen DMRequest anbietet. So könnte z.B. die File-Select-Box 
als DMRequester noch wesentlich vielseitiger ausgebaut werden. 
Dann müßten Sie nicht nur erlauben, einen File-Namen zu se¬ 
lektieren, der einer Funktion übergeben wird, sondern auch 
noch die Abfrage anbieten, ob gespeichert, geladen oder gelöscht 
werden soll. Dann kann jede Diskettenoperation ganz einfach 
über einen doppelten Druck auf die rechte Maustaste ausgelöst 
werden. Einfacher geht es wirklich nicht! 

Für den Programmierer ändert sich die Requester-Behandlung 
überhaupt nicht. Er kann den Requester auf die oben beschrie¬ 
bene Methode verarbeiten und auswerten. Der wesentliche Un¬ 
terschied liegt nur im Aufruf. Während konventionelle Requester 
durch eine Funktion vom Programm auf gerufen werden, ist 
dieser Requester nur definiert und kann irgendwann auf treten. 
Deshalb ist es wichtig, die IDCMP-Flags regelmäßig zu über¬ 
prüfen. Diese können das Auftreten des ersten Requesters ab¬ 
testen, denn bei den anderen vielleicht vorhandenen Requester- 
Routinen wird ClearDMRequest() vorher angesprungen. 

Ich wünsche noch viel Spaß bei der Requester-Programmierung! 
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3.6 Alerts, wenn es ernst wird 

Alerts sind enge Verwandte der Requester-Familie. Sie stehen an 
der Spitze der Dringlichkeit, aber leider am Ende der Program¬ 
mierfreundlichkeit. Beide, Requester und Alert, helfen, eine 
Entscheidung vom Benutzer zu verlangen. Gehen wir zuerst 
daran, die. Unterschiede herauszufinden. 

Requester sind weiterentwickelte Windows, die ausschließ¬ 
lich zur Informationssammlung dienen. Alerts sind Bild¬ 
schirmbereiche, die oft letzte Informationen vor einem 
Absturz bringen. 

Requester sind in ihrer Größe, Position und Gestaltung 
frei wählbar. Alerts verdrängen sogar immer alle Screens 
oder unterbinden deren Darstellung. Außerdem können 
Alerts nur oberhalb der Screens und auf voller Bildschirm¬ 
breite dargestellt werden. 

Requester bieten vielfältige Eingabemöglichkeiten, unter¬ 
stützt durch alle Gadget-Typen. Alerts lassen nur zwei 
verschiedene Eingaben über die beiden Maustasten zu. 

Requester blockieren nur den Task, vom dem sie aufgeru¬ 
fen wurden. Alerts legen das gesamte Multitasking-Be¬ 
triebssystem lahm. 

Sie wissen jetzt in etwa, welchen Bedeutungsunterschied die bei¬ 
den Kommunikationsmittel haben. Wir sollten Alerts in unseren 
Programmen immer nur dann verwenden, wenn es einer sehr 
wichtigen Klärung bedarf. 

Auch Intuition bringt neben den System-Requestern Alerts. In¬ 
tuition verwaltet nicht nur die bekannten Guru-Meditations, 
sondern wandelt auch einen AutoRequest in einen Alert um, 
wenn nicht genügend Speicher zur Verfügung steht, weil Alerts 
durch die spartanische Ausnutzung der grafischen Möglichkeiten 
wesentlich weniger Speicher verbrauchen. 

Achtung! Bedenken Sie immer, welchen Schock eine Warnmel¬ 
dung beim Benutzer auslöst und ob das gerechtfertigt ist! 
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3.6.1 Verwendungszwecke 

Ein Alert sollte nur bei ganz wichtigen Situationen angewendet 
werden. Würde man bei fast jeder Gelegenheit auf einen Alert 
zurückgreifen, wäre der Schock nicht mehr da! 

Das erste wichtige Anwendungsgebiet für Alerts liegt in dem 
"Nicht-Erreichen" bestimmter Ziele. Da kann einmal der Ver¬ 
such, eine Library zu öffnen, fehlgeschlagen sein, oder ein 
Screen konnte nicht geöffnet werden. Wir haben dafür während 
der Testphase in unseren Funktionen Open_All() und 
Close_A110 einen Text über printf() ausgegeben. Aber nicht 
immer hat der Benutzer das DÖS-Window geöffnet und darüber 
das Programm gestartet. Wenn dieser "Nachrichtenkanal" nicht 
offen ist, teilen wir die äußerst wichtige Nachricht über einen 
Alert mit. 

Dieser kann in jedem Fall benutzt werden, wenn z.B. irgend¬ 
welche Voraussetzungen nicht gegeben sind: Eine Steckkarte 
muß für den Betrieb eines Programms vorhanden sein. Oder die 
Arbeit ist in der vorliegenden Speicherausführung nicht aus¬ 
führbar. 

Alle genannten Gründe könnten einen Alert rechtfertigen, doch 
überlegen Sie immer, ob nicht ein einfacher AutoRequester ge¬ 
nügt. Immerhin legt der Alert den Ablauf des gesamten Systems 
lahm und wartet darauf, daß Sie reagieren. Dieser Alert muß in 
seiner Wichtigkeit also alle anderen Prozesse übertreffen! 


3.6.2 Aufbau und Einstellungen für einen Alert 

Die Funktion DisplayAlertO erwartet drei Daten, anhand derer 
der Alert aufgebaut wird. 

Zuerst übergeben wir die Alert-Nummer, aus der Intuition ab¬ 
liest, um welchen Alert-Typ es sich handelt. Man unterscheidet 
grundsätzlich zwei Typen, die am höchstwertigen Byte der 
LONG-Variable zu erkennen sind. Ein RECOVERY_ALERT - 
die Funktion kehrt nach der Darstellung wieder zurück zum 
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Programm - wird über 0 gekennzeichnet, einen DEADEND_ 
ALERT - nach der Darstellung erfolgt ein Reset - erkennt man 
am Byte 8. 

Weiterhin übergeben wir der Funktion die Höhe unseres Alerts 
in Bildschirmzeilen. Um diese werden später alle anderen 
Screens nach unten verschoben. 

Das wichtigste Datum ist der Pointer auf einen Alert-String, der 
aus einem String besteht, der noch um einige Informationen er¬ 
gänzt wurde: 

Der Alert-Text setzt sich zusammen aus vielen Alert-Strings, die 
über eine Endkennung verbunden sind. Am Anfang enthält je¬ 
der Alert-String eine Positionsangabe in Pixel. Darauf folgt der 
Text, der das Format eines normalen Strings hat. Abschließend 
finden wir ein Byte, das, wenn es ungleich NULL ist, einen 
weiteren String "einläutet". Ansonsten ist der Alert-Text damit 
abgeschlossen. 

\ 

Leider wird die doch etwas komplizierte Verwaltung eines Alerts 
wenig von Intuition unterstützt. Man hat leider die Struktur im 
Include-File nicht eingebunden, so daß ich sie hier nachreichen 
möchte. 

Zuerst richten wir eine Struktur für die Alert-Strings ein; 

struct AlertMessage 
< 

0x00 00 SHORT LeftEdge; 

0x02 02 BYTE TopEdge; 

0x03 03 char AlertTexttSOl; 

0x53 83 BYTE Flag; 

0x54 84 

>; 

Das einzige Problem, das bei der Definition der Struktur auf- 
tritt, ist die Länge des Textes. Wir müssen dafür einen Stan¬ 
dardwert nehmen. Sie können ihn aber nach Belieben ändern. 
Achten Sie nur darauf, daß der Alert in TOPAZ_SIXTY ausge¬ 
geben wird und damit maximal nur 60 Zeichen in der Zeile er¬ 
laubt sind. 
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Aufgrund der AlertMessage-Struktur können wir jetzt unseren 
eigenen Alert zusammenstellen. Dafür richten wir uns ein Feld 
aus dieser Struktur ein: 

«define NOEND OxFF 
#define END 0x00 

struct AlertMessage UserAlertü = 
i 

50, 24, " Dies ist der erste Alert meines Lebens!!! ", NOEND, 

50, 34, " . ", NOEND, 

50, 44, " ", NOEND, 

50, 54, " <Left Button> CANCEL <Right Button> RETRY", END 

>; 

Struktur 3,18: AlertMessage Test 

Denken Sie daran, daß jeder String innerhalb des Feldes mit der 
Kennung ergänzt werden muß. Um eine möglichst einfache 
Handhabung zu gewährleisten, habe ich dafür zwei Namen defi¬ 
niert. Mit NOEND kennzeichnen Sie, daß ein weiterer Text fol¬ 
gen wird, und mit END das Ende. 

Nachdem unsere erste Alert-Struktur definiert ist, können wir 
sie mit der DisplayAlert()-Funktion aufrufen. Diese hat folgen¬ 
des Format: 

Response = DisplayAlertCAlertNumber, String, Height); 

DO -90 DO AO A1 

In unserem Test-Programm setzten wir sie mit den bekannten 
Werten ein: 

Antwort = DisplayAlert(RECOVERY_ALERT, &UserAlert, SOL); 

Das ganze Programm sieht dann hoffentlich so aus: 
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y*************************************** 

★ * 

* Programn: Alert austesten * 

* ====ss=========ss=ss:===s==========s * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ ♦ 

* Wgb 29.12.1987 erster Alert * 

* * 

★ * 

***************************************/ 


#include <exec/types.h> 

#1 nc l ude < i ntui t i on/ i ntui 1 1 on. h> 


struct IntuitionBase *IntuitionBase; 

struct AlertMessage 

SHORT LeftEdge; 

BYTE TopEdge; 
char AlertText[50] ; 

BYTE Flag; 

>; 

#define NOEND OxFF 
#define END 0x00 

struct AlertMessage UserAlertC] = 
i 

50, 24, *' Dies ist der erste Alert meines Lebens!!! ", NOEND, 

50, 34, " . ", NOEND, 

50, 44, " ", NOEND, 

50, 54, " <Left Button> CANCEL <Right Button> RETRY", END 

>; 


mainO 

L 

BOOL Antwort; 

Open^AllO; 

Antwort = DisplayAlert(RECOVERY_ALERT, ÄUserAlert, 50L); 
if (Antwort == TRUE) 

printf("Linke Maustaste wurde gedrückt!\n"); 
eise 

printf("Rechte Maustaste wurde gedrückt!\n"); 

Close AllO; 

> 
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^***4r***********Sr*********************** 

* * 

* Funktion: Alles Nötige öffnen * 

* =====£===============:============== * 

* * 

* Autor: Datum: Kommentar: * 

ft _ ★ 

* Wgb 16.10.1987 nur Intuition 

* * 
fcftfcftftfcfcftftftftftftftftftftltfcftftftftftftftftftltftftftftltftftftftft^ 


Open Allo 

c 

void *OpenLibrary(); 

if (!(IntuitionBase = (struct IntuitionBase *) 
OpenL i brary(•• i ntui t i on. l i brary”, OL > ) ) 

< 

printf(“Keine Intuition Library gefunden!\n“); 

Close AlU); 

exit(FALSE); 

> 

> 


^ftftftftftftftftftftftft’kftftltltfiftft’kft’kftftftftftftltfcitftftftftftft* 
ft ft 

* Funktion: Alles Geöffnete schließen * 

* ======s=========s================== * 

* * 

* Autor: Datum: Kommentar: * 

ft _ ft 

* Wgb 16.10.1987 nur Intuition * 

* ★ 
ftftftftftftftftftfUtftftftftftftftftftftftftftftftftftftitltftftftftftltltft^ 


Close AHO 
i ” 

if (IntuitionBase) CloseLibrary(IntuitionBase); 

> 


Programm 3.7: Alert 

Programmbeschreibung 

Das Programm bereitet am Anfang alle nötigen Strukturen für 
den Funktionsaufruf vor. Dazu gehört es auch, die beiden 
Include-Files einzubinden, denn ohne deren Definitionen ist die 
Arbeit nicht möglich, wenn auch nur auf die Variablentypen 
und Alert-Types zurückgegriffen wird. 
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Ist der Alert-String mit allen Koordinaten und Kennungen defi¬ 
niert, kann das Hauptprogramm die Funktion Open_All() auf- 
rufen, damit der Zugriff zu Intuition gesichert ist. Danach wird 
DisplayAlertO gestartet und der Rückgabewert verarbeitet. Zum 
Schluß kann durch Close_All() alles wieder geschlossen werden. 

Hinweis: Um die Wirkung eines DEADEND_ALERT einmal 

auszuprobieren, sollten Sie ruhig den Alert-Type än¬ 
dern. Bedenken Sie nur, daß danach die Kontrolle 
nicht mehr an das Programm übergeben wird, son¬ 
dern an die Reset-Routine. 


3.6.3 Alerts für Programmprojekte 

Einen Alert in ein Programm einzubauen bedeutet für den Pro¬ 
grammierer Arbeit, die er sich ebensogut sparen könnte. Man 
versucht lediglich, die Bedienung eindeutiger und interessanter 
zu gestalten. 

Es empfiehlt sich deshalb, erst nach Abschluß aller Arbeiten an 
einem Programm noch zusätzlich Alerts einzubauen. Diese er¬ 
setzen dann meist Fehlermeldungen, die in der Testphase immer 
in das DOS-Window ausgegeben wurden. Deren Programmierung 
ist zwar sehr einfach, doch entbehrt sie jeder Professionalität! 

Für das nachträgliche Einbinden der Alerts empfehle ich fol¬ 
gende Systematik: Ist ihr Programm fertiggestellt und stehen alle 
Punkte im Programmtext fest, an denen eine einfache Abbruch- 
Meldung durch einen Alert ersetzt werden soll, müssen wir zu¬ 
erst die Texte entwickeln, die später in bestimmten Situationen 
ausgegeben werden sollen. 

Dafür empfehle ich ein allgemeines Aussehen (Design) aller 
Alerts und vielleicht einen "Multi-Alert", in dem nur eine Spe¬ 
zifikation eingesetzt wird. Aber das nur am Rande. Alle Alert- 
Texte werden dann gesondert mit der Strukturdefinition in ein 
File geschrieben. Dieses File wird als letztes "included": 
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#include <exec/devices.h> 
#include <graphics/gfxbase.h> 


# 1 ncludes ”Disk:Verzeichnis/Alert” 

In dem Alert-File finden wir z.B. für die Textverarbeitung die 
folgenden Fehlermeldungen: 


^★4r*****4r*********************************** 

* * 

* include : Alert-Struktur mit Definition * 

* sssssssssssssssssssssssssssssssssssssss * 

* * 

* Autor: Datum: Kommentar: * 

★ .. ★ 

Ugb 29.12.1987 für Text Verarbeitung* 

* ♦ 

*******************************************^ 


#include <exec/types.h> 

#include <intuition/intuition.h> 


struct AlertMessage 
i 

SHORT LeftEdge; 

BYTE TopEdge; 
char AlertText[50]; 
BYTE Flag; 


#define NOEND OxFF 
#define END 0x00 


struct AlertMessage OutMem[] = 


50, 24, 
50, 34, 
50, 44, 
50, 54, 
50, 64, 


Es stand nicht genügend Speicherplatz zur 
Verfügung! Bitte machen Sie Speicher frei! 
Starten Sie danach das Programm neu! 

Maustaste für Bestätigung 


', NOEND, 
•, NOEND, 
*, NOEND, 
*, NOEND, 
*, END 


#define OutMemSize 801 


struct AlertMessage NoLibraryC] = 
i 
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", NOEND, 
", NOEND, 
", NOEND, 
", NOEND, 
", NOEND, 
", END 

>; 

#define NoLibraySize 90L 


50, 24, 
50, 34, 
50, 44, 
50, 54, 
50, 64, 
50, 74, 


Die graphics.library konnte nicht geöffnet 
werden! Das Progranm bricht deshalb ab! 
Sorgen Sie dafür, daB diese Library auf 
der Workbench zu finden ist! 

Maustaste für Bestätigung 


struct AlertHessage Ende[] = 

< 

50, 24, " Lebenswichtige Funktionen können nicht 
50, 34, " erreicht werden! 

50, 44, " . Crash! Crash! . uff 

50, 54, " 

50, 64, " Maustaste für Bestätigung 

>; 


", NOEND, 
", NOEND, 
", NOEND, 
", NOEND, 
", END 


#define Endesize BOL 


Programm 3.8: Alert-Texte 

Für den Aufruf von DisplayAlert() habe ich zusätzlich die 
benötigte Höhe jedes Alerts in einem Define abgelegt. Im Pro¬ 
grammtext werden dann folgende Zeilen 

if (Window == NULL) 

C 

printf("Leider kein Window zu öffnen!\n"); 

Close AlU); 
exit(?ALSE); 

> 


durch diese ersetzt: 


if (Window == NULL) 

r 

DisplayAlert(RECOVERY_ALERT, ANoWindow, NoWindowSize); 

Close_AU(); 

exit(FALSE); 

> 
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3.6.4 Auswertung der Guru-Meditation 

Auch wenn Sie noch keine Alerts selber programmiert haben, so 
haben Sie sicherlich schon Bekanntschaft mit den Gurus ge¬ 
macht. Doch im allgemeinen nimmt man die Meldung meist nur 
am Rande wahr, da ja sowieso nichts dagegen unternommen 
werden kann. Damit aber wird der Sinn einer Guru-Meditation 
verdreht! Der Amiga könnte ja auch sang- und klanglos abstür- 
zen, ohne sich noch einmal zu melden. Die Gurus wurden aber 
extra eingeführt, damit der Anwender noch die Nachricht erhält, 
warum das Betriebssystem einen Neustart auslösen mußte. 

Das ist besonders wichtig, wenn man selber programmiert. Denn 
nur so weiß man, warum das eigene Programm in der Testphase 
fehlerhaft lief und wo die Fehlerquelle zu suchen ist. Das ein¬ 
zige Problem der Guru-Meditation ist aber, daß wir immer nur 
den gleichen Text erhalten und eine Nummer, mit der keiner 
etwas anfangen kann. Das soll sich jetzt ändern. Aus den folgen¬ 
den Tabellen werden Sie alle Informationen schöpfen können, 
die Ihnen die Decodierung jedes Gurus ermöglichen. 

Die Guru-Nummer setzt sich aus mehreren Segmenten zusam¬ 
men. Wir können sie deshalb in ein allgemeines Format bringen: 

Guru Meditation : TTSSFFGGGG.AAAAAAAA 

Die Buchstaben haben folgende Bedeutung: 

TT Alert_Type 

SS Systemklasse 

FF Fehlerklasse 

GGGG Genauere Beschreibung. 

AAAAAAAA Adresse des fehlerauslösenden Tasks. 

Für TT gibt es nur zwei Möglichkeiten. Sie kennen diese Werte 
unter der Bezeichnung Alert_Type. Entweder es handelt sich um 
einen DEADEND oder einen RECOVERY_ALERT. Nur der 
letzte Typ kehrt wieder zurück! 
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Alert_Types 

00000000 RECOVERY_ALERT 

80000000 DEADEND ALERT 


Tabelle 3.14: Alert-Types 

Hier noch eine Information zur Schreibweise. Bei allen Werten 
schreibe ich den ganzen Term auf. Bei Kombinationen werden 
diese mit ”oder” verknüpft! 

Als nächstes steht die Systemklasse zur Diskussion. Hier finden 
wir die Bezeichnung des "Subsystems”, in dem der Fehler aufge¬ 
treten ist. 


SUBSYSTEM_CODE 

00000000 68000er 


LIBRÄRYS 

01000000 

02000000 

03000000 

04000000 

05000000 

06000000 

07000000 

08000000 

09000000 

OAOOOOOO 

DEVICES 

10000000 

11000000 

12000000 

13000000 

14000000 

15000000 

RESOURCES 

20000000 

21000000 

22000000 


exec.library 

graphics.library 

layers.library 

intuition.library 

math.library 

clist.libraiy 

dos.library 

ram.library 

icon.library 

expansion.library 


audio.device 
console.device 
gameport .device 
key board .device 
trackdifk.device 
timer .device 


CIA 

Disk 

Mise 
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MISC 

30000000 

31000000 

32000000 


Bootstrap 

Workbench 

DiskCopy 


Tabellen 3.15: Subsystem-Codes 


Beachten Sie die Fehlermeldung am Anfang der Subsystem-Li¬ 
ste! Hier meldet sich der Prozessor selbst zu Wort! Wenn dies der 
Fall ist, so handelt es sich um einen Prozessor-Trap. Die restli¬ 
chen Stellen der Guru-Meditation erhalten dadurch eine andere 
Bedeutung: 

TRAP_CODES 

00000002 Daten- oder Adreßbus-Fehler beim Takten. 

00000003 Adressierungsfehler (ungerade Adresse). 

00000004 Illegal Instruktion. 

00000005 Division durch Null. 

00000006 CHR Instruktion. 

00000007 TRAPV Instruktion. 

00000008 Privileg-Verletsung. 

00000009 Einselschrittmodus. 

OOOOOOOA Line A Emulator (OpCode 1010). 

OOOOOOOB Line F Emulator (OpCode 1111). 


Tabelle 3.16: Trap-Codes 


War es aber ein Fehler nach der Subsystem-Liste, dann können 
wir ihn weiter spezifizieren. Über ^Fehlerklasse" erfahren wir 
genaueres zum Grund des Fehlers: 


ERRORJCLASS 

00010000 

00020000 

00030000 

00040000 

00050000 

00060000 

00070000 


Nicht genügend Speicher. 

Library konnte nicht aufgebaut werden. 
Library konnte nicht geöffnet werden. 
Device konnte nicht geöffnet werden. 
Keine Reaktion der Hardware. 
I/O-Fehler. 

I/O nicht vorhanden. 


Tabelle 3.17: Error-Classes 
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Über die letzten vier Stellen der Fehlernummer bekommen wir 
noch detailliertere Informationen. Diese sind allerdings auf die 
Subsysteme spezifiziert. 


exec.library 

01000000 

81000002 

81000003 

81000004 

81000005 

81000006 

81000007 

81000008 

81000009 

8100000A 

graphicsJibrary 

82010001 
82010002 
82010003 
82010004 
82010005 
82010006 
82010007 
82010008 
82010009 
8201000A 
8201OOOB 
82010030 
82011234 

layers.library 

03000001 


Prüfsummenfehler bei Ausnahmen der CPU. 
Prüfsummenfehler der Startadresse. 
Prüfsummenfehler einer Library. 

Nicht genug Speicher für Library. 

Fehlerhafter Speicherlisteneintrag. 

Nicht genug Speicher für Interrupt. 

Zeiger > Fehler. 

Fehlerhafte Semaphore. 

Speicherbereich wurde sum sweiten Mal freigegeben. 
Zeiger-Fehler bei Ausnahme. 


Nicht genug Speicher für die Copper-Liste. 

Nicht genug Speicher für die Copper-Instruktions-Liste. 
Die Copper-Liste ist vollständig belegt. 

Aufteilungs-Fehler in der Copper-Liste. 

Nicht genug Speicher für den Copper-Listen-Kopf. 

Nicht genug Speicher für "long frame**. 

Nicht genug Speicher für "short frame". 

Nicht genug Speicher für die Fill-Routine. 

Nicht genug Speicher für die Text-Routine. 

Nicht genug Speicher für die BlitterBitMap. 

Falscher Speicherbereich. 

Fehler während des Einrichtens eines ViewPorts. 
GfxNoLCM (kein Zwischenspeicher vorhanden). 


Nicht genug Speicher für Layers. 


intuition.library 

84000000 

04000001 

84010002 

04010003 

04010004 

84010005 

84000006 

84010007 

84010008 


Gadget-Typ ist unbekannt. 

Typenfehler beim AN_Gadget. 

Nicht genug Speicher für Erstellung eines Ports. 
Nicht genug Speicher für ein Menü. 

Nicht genug Speicher für ein Sub-Menü. 

Nicht genug Speicher für die Menü-Leiste. 

Falsche Position der Menü-Leiste. 

Nicht genug Speicher für OpenScreen(). 

Nicht genug Speicher für Erstellung eines RastPorts. 
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84000009 
8401OOOA 
8401OOOB 
8400000C 
84000000 
8400000E 
8400000F 

dos.library 

07000001 

07000002 

07000003 

07000004 

07000005 

07000006 

07000007 

07000008 

07000009 

0700000A 

0700000B 

0700000C 

ramJibrary 

08000001 


Unbekannter oder fehlerhafter SCREEN_TYPE. 

Nicht genug Speicher für Gadget. 

Nicht genug Speicher für Window. 

Statusregister hat falschen Status beim öffnend. Library. 
Falsche Message über den IDCMP. 

Nicht genug Speicher für Message-Stack. 

Nicht genug Speicher für Console.Device. 


Nicht genug Speicher beim StartUp. 
Der Task wurde nicht beendet. 

Qpkt-Fehler ist aufgetreten. 
Datenpaket wurde nicht erwartet. 
Freier Zeiger ist nicht erreichbar. 
Fehlerhafte Daten eines Disk-Blocks. 
Die BitMap ist serstört. 

Key wurde schon freigegeben. 

Die Prüfsumme ist fehlerhaft. 

Disk Error. 

Key außerhalb des erlaubten Bereichs. 
Falsches Überschreiben. 


Fehlerhafter Eintrag in der Verwaltungsliste. 


expansionJibrary 

0A000001 

trackdisk.device 

14000001 

14000002 

timer.device 

15000001 

15000002 

disk.resource 

21000001 

21000002 


Fehler bei Erweiterung der Hardware. 


Fehler während des Suchens. 

Fehler beim Timer-Impuls: Verzögerung. 


Fehler beim Zugriff auf das Device. 

Fehler bei Zeitkoordinierung: Netzschwankungen. 


Eingelegte Diskette wurde nicht erkannt. 
Unterbrechung, da kein Laufwerk angeschlossen ist. 


bootstrap 

30000001 Fehler beim Auswerten der Boot-Daten. 

Tabelle 3.18: Fehlermöglichkeiten 
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3.7 Abfrage des IDCMP 

Ein Programm kann erst richtig "leben", wenn es mit seinem Be¬ 
nutzer kommuniziert. Wir wollen kleine Demonstrationspro¬ 
gramme schreiben und brauchen deshalb immer wieder Ent¬ 
scheidungen und Eingaben während des Programmablaufs. Hier 
stellt sich zunächst die Frage: 

"Wie bekomme ich die Informationen vom Benutzer?" 

Als Antwort bietet das Amiga-System mehrere Ein- und Ausga¬ 
begeräte und Datenleitungen. Dies sind im einzelnen das 
Audio.Device, Timer.Device, Trackdisk.Device, Console.Device, 
Input.Device, Keyboard.Device, Gameport.Device, Narra- 
tor.Device, Serial.Device, Parallel.Device, Printer.Device und das 
Clipboard.Device. Nicht alle von ihnen lassen Ein- und Ausgabe 
gleichzeitig zu. 

So können wir über das Audio.Device, Narrator.Device und 
Printer.Device nur Daten senden. Umgekehrt erlauben es das 
Timer.Device, Keyboard.Device und das Gameport.Device sinn¬ 
vollerweise nur, Daten zu empfangen. Mit den anderen Devices 
können wir in beiden Richtungen Daten austauschen. Erst das ist 
eine richtige Kommunikation. 

Allerdings haben alle diese Ein- und Ausgabegeräte einen 
Nachteil. Wollen Sie nämlich mehrere Daten verschiedenen Typs 
senden und empfangen, so brauchen Sie mehr als ein Device. 

Manche Devices bieten auf bestimmten Gebieten Vorteile, auf 
anderen aber starke Nachteile. Die Folge davon ist es, daß im 
Programm etliche Devices geöffnet werden, aber der Program¬ 
mierer am Ende einfach die Übersicht verliert. 

Aus diesem Grund haben sich die Entwickler des Amiga Gedan¬ 
ken gemacht, und herausgekommen ist der IDCMP! Er ist eine 
Synthese aus Input.Device, Gameport.Device, Timer.Device, 
Trackdisk.Device und Console.Device mit Verknüpfung der In¬ 
tuition-Einrichtungen. 
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Trackdisk.Device und Console.Device mit Verknüpfung der In¬ 
tuition-Einrichtungen. 

Der IDCMP ist gedacht zur Datenverarbeitung, Filterung und 
Bereitstellung. Über das ihm zugeordnete Window können Sie 
einstellen, welche Daten Sie erhalten wollen und welche er in ein 
passendes Format umsetzen soll. Oder möchten Sie die Daten lie¬ 
ber unverändert lassen? Auch das erlaubt der IDCMP. Die Aus¬ 
gabe wurde bei der Entwicklung nicht beachtet. Sie läuft über 
die Grafik-Unterstützung von Intuition. Möchten Sie noch mehr 
Flexibilität, dann weichen Sie aus auf die "graphics.library". Es 
hat sich aber herausgestellt, daß Intuition im Normalfall voll¬ 
kommen ausreichend ist. Alle Eingaben lassen sich über IDCMP 
empfangen, und Ausgaben sind mit den Grafik-Strukturen ein¬ 
fach und komfortabel möglich. 

Lassen Sie sich entführen in das Reich des IDCMP, und bewun¬ 
dern Sie die Möglichkeiten und die Vielfalt der Eingaben. 


3.7.1 Vorbereitung und Nachrichtenempfang 

Der IDCMP steht dem Programmierer nicht selbstverständlich 
zur Verfügung. Intuition muß erkennen, daß eine Notwendigkeit 
für den Datenempfang besteht. 

Als Grundvoraussetzung für den IDCMP benötigen wir ein Win¬ 
dow. Ohne Window ist es nicht möglich, Daten über Intuition zu 
empfangen. Erinnern Sie sich jetzt bitte an die NewWindow- 
Struktur. Unter dem Eintrag IDCMPFlags besteht die Verbin¬ 
dung zu unserem "Intuition Direct Communication Message 
Ports". Wenn wir dort mit einem Flag kennzeichnen, daß wir an 
Informationen interessiert sind, richtet Intuition für dieses Win¬ 
dow einen Port ein. Um das Gebiet abzustecken, für das wir den 
Port benutzen können, ist es zuerst wichtig zu wissen, welche 
Flags gesetzt werden können. Diese unterteilen sich in sechs 
Gruppen. 


In der ersten Gruppe finden wir die wichtigsten Flags. Sie be¬ 
ziehen sich auf das Window des Message-Ports: 
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SIZEVERIFY 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der Benutzer versucht, die Größe des Windows 
zu verändern. Das kann wichtig sein, wenn das Programm gerade 
zeichnet und diese Arbeit beendet sein muß, bevor die Größe 
verändert wird. Dann kann das Window nicht eher in der Größe 
geändert werden, bevor auf die Nachricht geantwortet worden 
ist. 

NEWSIZE 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn die Größe des Windows verändert wurde. Die 
Werte können aus der Window-Struktur ausgelesen werden. 

REFRESHWINDOW 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der Inhalt des Windows neu gezeichnet werden 
muß. Es ist nur bei den Window-Typen SIMPLE_REFRESH 
und SMART REFRESH sinnvoll. SMART REFRESH-Windows 
benötigen das Refresh-Flag auch nur dann, wenn sie mit einem 
Sizing-Gadget versehen sind. 

ACTIVATEWINDOW 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn das Window aktiviert wurde. 

INACTIVATEWINDOW 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn ein anderes Window aktiviert wurde. 

Die zweite Gruppe bearbeitet das Problem der Gadget-Handha¬ 
bung. Diese Flags haben Sie schon bei unseren Gadget-Abfragen 
kennengelernt; 

GADGETDOWN 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn ein Gadget angeklickt wurde, das vom Typ 
GADGIMMEDIATE ist. 
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GADGETUP 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn ein Gadget angeklickt wurde, das vom Typ 
RELVERIFY ist. 

CLOSEWINDOW 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn vom Benutzer das Close-Gadget betätigt wird. 
Intuition schließt das Fenster nicht! 

In der dritten Gruppe finden wir die erweiternden Flags zu den 
Gadgets wieder. Hier steht alles, was ein Requester auslösen 
kann: 

REQSET 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der erste Requester im Window geöffnet wird. 

REQCLEAR 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der letzte Requester im Window geschlossen 
wird. 

REQVERIFY 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn Intuition versucht, den ersten Requester zu 
öffnen. Intuition wartet dann so lange, bis auf die Nachricht 
geantwortet wird. So können Sie alle Ausgaben fertigstellen, be¬ 
vor der Requester erscheint. Werden weitere Requester im Win¬ 
dow geöffnet, so gibt Intuition keine Nachricht. Es wird davon 
ausgegangen, daß während der Requester-Bearbeitung die Aus¬ 
gabe gesichert ist. 

Die vierte Gruppe behandelt die Menü-Auswertung. Wenn Ihnen 
die Programmierung der Menüs noch nicht bekannt ist, so lesen 
Sie im nächsten Kapitel mehr dazu. 
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MENUPICK 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der Benutzer den Menü-Button gedrückt und 
wieder losgelassen hat. Es ist nicht gesichert, daß ein Menüpunkt 
ausgewählt wurde! 

MENUVERIFY 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn versucht wird, die Menüs zu aktivieren. So 
lange, wie nicht über ReplyO geantwortet wird, können die 
Menüs nicht dargestellt werden. 

Für die Mausabfrage sind die Flags der fünften Gruppe vorge¬ 
sehen: 

MOUSEBUTTONS 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn ein Maus-Button gedrückt oder losgelassen 
wurde. Beachten Sie, daß keine Nachrichten gesendet werden, 
wenn der linke Button über einem Gadget gedrückt oder wenn 
der rechte Button zur Handhabung der Menüs verwendet wird. 

MOUSEMOVE 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der Benutzer die Maus bewegt. Beachten Sie, 
daß dadurch sehr viele Nachrichten entstehen können, die auch 
noch alle verarbeitet werden müssen! Zusätzlich muß auch das 
REPORTMOUSE-Flag gesetzt sein oder, bei einem Gadget, das 
FOLLOWMOUSE-Flag. 

DELTAMOVE 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn der Benutzer die Maus bewegt. Im Unterschied 
zum obigen Flag erhalten wir aber nicht die absoluten Positi¬ 
onswerte, sondern die Differenz zur vorhergehenden Position. 

In der letzten, der sechsten, Gruppe unserer IDCMP-Flags fin¬ 
den wir die übrigen, die sich nicht einordnen ließen. Das heißt 
aber nicht, daß diese Flags weniger brauchbar sind. Sie erfüllen 
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sogar Aufgaben, die manches Programm erst in die Klasse "pro¬ 
fessionell" erheben. 

INTUITICKS 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn eine zehntel Sekunde vergangen ist. (Dies ist 
die Einbindung des Timer.De vice.) Man erhält nur weitere IN- 
TUITICK-Nachrichten, wenn auf die letzte geantwortet wurde. 
So verhindert IDCMP eine "Nachrichtenschwemme"! 

NEWPREFS 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn die Preferences-Werte geändert wurden. Das ist 
z.B. wichtig, wenn sich das Programm auf die Farbeinstellungen 
oder den Drucker verläßt. Jedes Window, in dem dieses Flag 
gesetzt wurde, erhält eine Nachricht. Allerdings kann ein Pro¬ 
gramm, das die Preferences-Daten verändert, bestimmen, ob es 
dies den anderen mitteilen will. 

DISKINSERTED 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn eine Diskette in ein Laufwerk eingelegt wurde. 
Jedes Window, in dem dieses Flag gesetzt wurde, erhält eine 
Nachricht. (Dies ist die Einbindung des Trackdisk.Device.) 

DISREMOVED 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn eine Diskette aus dem Laufwerk genommen 
wurde. Jedes Window, in dem dieses Flag gesetzt wurde, erhält 
diese Nachricht. 

RAWKEY 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn eine Taste der Tastatur gedrückt wurde. Der 
Tastatur-Code ist aber "unbehandelt", d.h. daß Sie keinen nach 
der Tasturtabelle umgewandelten Code empfangen. (Dies ist die 
Einbindung des Input.Device.) 
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VANILLAKEY 

Ist dieses Flag gesetzt, so erhält das Programm immer dann eine 
Nachricht, wenn eine Taste gedrückt wurde. Der Tastur-Code ist 
nach der Tastaturtabelle verarbeitet und umgewandelt. (Dies ist 
die Einbindung des Console.Device.) 

Abschließend finden Sie hier alle Flags mit ihren Hex-Werten: 


Flag-Name 

Hex-Wert 

SIZEVERIFY 

0x00000001L 

NEUSIZE 

OxOOOOOOOZL 

REFRESHUINDOW 

0x00000004L 

ACTIVEWINDOW 

0x00040000L 

INACTIVEUINDOU 

OxOOOSOOOOL 

GADGETDOWN 

OxOOOOOOZOL 

GADGETUP 

0x00000040L 

CLOSEUINDOU 

OxOOOOOZOOL 

REQSET 

OxOOOOOOSOL 

REQCLEAR 

0x00001OOOL 

REQVERIFY 

OxOOOOOSOOL 

MENUPICK 

0x000001OOL 

MENUVERIFY 

OxOOOOZOOOL 

MOUSEBUTTONS 

OxOOOOOOOBL 

MOUSEMOVE 

0x0000001OL 

DELTAMOVE 

0x001OOOOOL 

INTUITICKS 

0x00400000L 

NEUPREFS 

0X00004000L 

DISKINSERTED 

OxOOOOBOOOL 

DISKREMOVED 

0x0001OOOOL 

RAWKEY 

0X00000400L 

VANILLAKEY 

OxOOZOOOOOL 

UBENCHMESSAGE 

OxOOOZOOOOL 

LONELYMESSAGE 

OxSOOOOOOOL 

Tabelle 3.19: Alle IDCMP-Flags 


Bemerkung 

Window-Flags 

Gadget-Flags 

Requester- Flags 

Menü-Flags 

Maus-Flags 

Timer.Device 
Preferences-Änderung 
Trackdisk.Device 

Input .Device 
Console.Device 

W orkbench - N achrich t 

Keine Intuition-IDCMP-Nachricht 
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Haben Sie sich entschieden, zu welchen Gebieten Sie Nachrich¬ 
ten und Informationen empfangen möchten, so gibt es zwei 
Wege, über die Sie es dem System mitteilen können. Der erste 
und auch der einfachste: Sie setzen gleich in der NewWindow- 
Struktur die entsprechenden Flags ein. Intuition richtet dann 
sofort den IDCMP ein, und Sie brauchen sich nur noch um die 
Abfrage zu kümmern. Der zweite Weg: Sie wollen Nachrichten 
empfangen und haben schon ein Window geöffnet, ohne aber 
einen Port einzurichten. In diesem Fall nutzen Sie die Funktion 
ModifyIDCMP(). Übergeben Sie ihr einfach den Window-Pointer 
und alle zu setzenden IDCMP-Flags. Der Befehl hat folgendes 
Format: 

ModifyIOCMP(Uindow, IDCMPFlags); 

-150 AO 00 

Danach wird entweder ein neuer Port eingerichtet oder ein be¬ 
stehender geschlossen. Die dritte Möglichkeit wandelt nur die 
vorhandenen Flags in die neuen Flag-Werte um. 

Zum zweiten Weg zählen auch Funktionen wie z.B. Report- 
MouseO, die den IDCMP beeinflussen. Auch hier geschieht das 
gleiche, aber nur in bezug auf ein einziges Flag. 


3.7.1.1 Die IntuiMessage-Struktur 

Nachdem wir ausreichend geklärt haben, zu welchen Situationen 
uns der IDCMP Nachrichten liefern kann, ist es jetzt an der 
Zeit, sich die Nachrichtenübermittlung genauer anzusehen. 

In der Window-Struktur finden wir an Byte 90 einen Zeiger auf 
die IntuiMessage-Struktur mit dem Namen MessageKey. Außer¬ 
dem finden wir schon bei Byte 82 einen weiteren Zeiger auf 
einen MessagePort mit dem Namen UserPort und gleich darauf 
den MessagePort WindowPort. Zusammen mit diesem drei Messa- 
gePorts lassen sie die Eingaben verarbeiten. 


Sehen wir uns zuerst die IntuiMessage-Struktur an: 
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struct IntuiMessage 

0x00 00 struct Message ExecMessage; 

0x00 00 struct Node mn_Node; 

0x00 00 struct Node *ln_Succ; 

0x04 04 struct Node *ln_Pred; 

0x08 08 UBYTE ln Type; 

0x09 09 BYTE ln_Pri; 

OxOA 10 char *ln Naoie; 

OxOE 14 

OxOE 14 struct MsgPort *mn_ReplyPort; 

0x12 18 UWORD im Length; 

0x14 20 

0x14 20 ULONG dass; 

0x18 24 USHORT Code; 

OxIA 26 USHORT Qualifier; 

OxIC 28 APTR lAddress; 

0x20 32 SHORT HouseX; 

0x22 34 SHORT MouseY; 

0x24 36 ULONG Seconds; 

0x28 40 ULONG Micros; 

0x2C 44 struct Uindow *IDCMPUindow; 

0x30 48 struct IntuiMessage *SpecialL1nk; 

0x34 52 

>; 

Strukturbeschreibung 

Die Struktur enthält am Kopf eine eingebundene Message- 
Struktur. Diese wird für den Datentransport der Messages von 
Exec gebraucht. Interessant wird es erst bei den anderen Werten, 
die zusätzlich zu der auslösenden Information noch wichtige 
Daten beinhalten können. Das ist vom Flag abhängig. 


ExecMessage wird hauptsächlich von Exec dazu gebracht, die 
Message in das System einzubinden. 


Class ist eine ULONG-Variable, die die Art der gesendeten 
Daten kennzeichnet. Die Bits sind mit den möglichen der Win¬ 
dow-IDCMP-Variablen identisch und können zur Identifizierung 
der Nachricht gebraucht werden. 

Code enthält Daten, die vom auslösenden Flag abhängen. Der 
Wert hat immer andere Bedeutungen. 


Qualifier ist eine Kopie der ie_Qualifier-Variablen, die vom 
Input.Device übertragen wird. 
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MouseX, MouseY enthalten die Mauskoordinaten in bezug auf 
das Window zum Zeitpunkt der Nachrichtenübermittlung. 

Seconds, Micros ist eine Kopie der System-Uhrzeit des Amiga 
zum Zeitpunkt der Nachrichtenübermittlung. 

lAddress ist ein Zeiger auf die Struktur, in der man die Nach¬ 
richt findet. Das kann z.B. eine Gadget-Struktur sein, von der 
der Impuls ausgelöst wurde. 

IDCMPWindow ist ein Zeiger auf das Window, von dem die 
Nachricht stammt. 

SpecialLink ist eine Variable, die vom System benutzt wird. Wie 
Sie sehen, enthält die IntuiMessage-Struktur alle Daten, die für 
die Weiterverarbeitung wichtig sein können. Wir finden hier 
hauptsächlich auf Intuition bezogene Daten, deren Auswertung 
aber stark vom erhaltenen Impuls abhängig ist. 


3.7.1.2 Die MsgPort-Strukturen 

Der Auslöser, über den wir den Empfang der Nachricht signali¬ 
siert bekommen, liegt aber nicht in der IntuiMessage-Struktur. 
Dafür haben wir die MsgPort-Struktur mit dem Namen User- 
Port. Über das Setzen eines Bits in der Variablen mp_SigBit 
können wir auf eine Nachricht warten. Die Struktur enthält 
außerdem noch die folgenden Elemente: 

struct MsgPort 

i 

0x00 00 struct Node mp^Node; 

0x00 00 struct Node *ln_Succ; 

0x04 04 struct Node *ln Pred; 

0x08 08 UBYTE ln Type; " 

0x09 09 BYTE ln_Pri; 

OxOA 10 eher *ln Name; 

OxOE 14 

OxOE 14 UBYTE mp Flags; 

OxOF 15 UBYTE mp'sigBit; 

0x10 16 struct Task *fnp_SigTask; 

0x14 20 struct List mp MsgList; 

0x22 34 

>; 
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Strukturbeschreibung 

In die Struktur ist am Kopf eine Node-Struktur eingebunden, 
die für die Erkennung des Ports hilfreich ist. 

mp_Flags kennzeichnet die Art der Message; 

PA_SIGNAL wird gesetzt, wenn eine Nachricht ankommt. 
PA_SOFTINT löst einen Software-Interrupt aus. 

PA_IGNORE kennzeichnet Nachrichten, die nicht beachtet 
werden sollen. 

mp_SigBit ist die uns betreffende Variable. Das gesetzte Bit 
stellt die Ankunft eines Task-Signals für uns dar. 

mp_SigTask ist ein Pointer auf den Task, der das Signal ausge¬ 
löst hat. 

mp_MsgList ist der Kopf einer Liste aller Messages, die zu 
diesem Port gesendet wurden. 

Sicher werden Sie etwas verwirrt sein, wenn Sie dies alles gele¬ 
sen haben. "Wir wollten doch nur ganz einfach den IDCMP ab- 
fragen!", werden Sie sagen. 

Sicherlich ist dieser MsgPort nicht ganz einfach, da er voll ins 
interne Signalsystem des Amiga eingreift. Aber’für den IDCMP 
müssen Sie eigentlich nur die Variable mp_SigBit verstehen. 

Mit ihr werden wir später darauf warten, daß eine Nachricht für 
uns ankommt. Es ist nicht einmal wichtig, was dort genau steht. 


3.7.1.3 Das Warten auf eine Nachricht 

Gehen wir davon aus, daß Intuition für uns MessagePort und 
IntuiMessage-Struktur eingerichtet hat. Unser Programm soll 
jetzt so lange verweilen, bis es eine Nachricht empfängt, die es 
auswerten kann. 
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Dafür ist es am besten, wenn wir erst einmal nachsehen, ob eine 
Nachricht auf dem UserPort anliegt. Mit der Exec-Funktion 
GetMsgO können wir das: 

Message = GetMsg(Window->UserPort); 

Als Ergebnis erhalten wir entweder einen Zeiger auf die Mes¬ 
sage-Struktur - in diesem Fall ist das eine IntuiMessage-Struktur 
- oder einen Null-Pointer, der uns unverbindlich mitteilt, daß 
keine Nachricht vorhanden ist. Nun könnte man ständig diese 
Abfrage wiederholen, bis endlich eine Nachricht anliegt. Das 
würde so aussehen: 

FOREVER 

i 

if (message = (struct IntuiMessage *) 

GetMsgCFirstWindow->UserPort)) 

< 

/* Auswertung */ 

> 

> 

Programmteil 3.8: IDCMP-Abfrageschleife (Grundaufbau) 

Wir hätten dann zwar eine wunderbare Nachrichten-Abfrage, 
doch besonders die anderen Tasks unseres Multitasking-Compu¬ 
ters würden sich freuen (Ironie!). Denn obwohl überhaupt nichts 
zu tun ist, arbeitet unser Programm ständig daran, immer wieder 
Nachrichten zu lesen, die ja vielleicht gar nicht vorhanden sind. 
Besser wäre es, wenn der Task in den "Ruhestand" versetzt wird, 
bis eine Nachricht gesendet wurde. Auch dafür gibt es einen 
Exec-Befehl. Mit Wait() erteilen Sie dem System den Auftrag, 
daß es den Task so lange nicht mehr abarbeiten soll, bis für ihn 
eine Nachricht abgelegt wird, ln unserem Fall sähe das so aus: 

FOREVER 

i 

if ((message - (struct IntuiMessage *) 

GetMsg(FirstWinciow->UserPort)) == NULL) 
i 

UaitdL « FirstWindow->UserPort->mp_SigBit); 
continue; 

> 

/* Auswertung */ 

> 

Programmteil 3.9: IDCMP-Abfrageschleife (verbesserte Version) 
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Zuerst wird ganz gewöhnlich der UserPort auf eine Nachricht 
hin untersucht. Liegt keine Nachricht vor, lassen wir das System 
so lange warten, bis es eine empfängt. Dann soll es am Anfang 
der Schleife die Programmausführung fortsetzen. Liegt aber eine 
Nachricht an, so wird sofort mit der Auswertung begonnen. Das 
ist auch dann der Fall, wenn das System aus dem Wait-Status 
zurückkehrt. 

Dann beginnt die Schleife von vorne, wo wir die erhaltene 
Nachricht einiesen. Diese ist in jedem Fall da und die Auswer¬ 
tung kann beginnen. 


3.7.2 Wir werten die Nachrichten aus 

Nachdem Sie nun ausführlich über die Möglichkeiten des Nach¬ 
richtenempfangs über den UserPort informiert sind, möchte ich 
damit beginnen. Ihnen die Auswertung zu erklären. 

Die ist vollkommen davon abhängig, welche Art von Nachrich¬ 
ten empfangen werden. Wir benötigen getrennte Auswertungen 
für Gadgets, Menüs, Requester, Keyboard und Maus. Durch 
diese strikte Unterteilung erhöht sich zwar der Programmierauf¬ 
wand etwas, wir haben dafür aber eine sehr hohe Flexibilität. 

Außerdem unterstüzt die Sprache C unser Vorhaben vorbildlich, 
so daß es überhaupt keine Mühe macht, die Abfragen zu pro¬ 
grammieren. Wenn man erst weiß, wie es geht... 

Wenn wir mit Sicherheit eine Nachricht empfangen haben, geht 
es an die Vorauswertung. Wir müssen zuerst einmal feststellen, 
in welche Gruppe die Nachricht fällt, d.h. welchen Flag-Wert 
die C/ass-Variable der IntuiMessage-Struktur enthält. 

Für diese Überprüfung holen wir standardmäßig einige Werte 
aus der Struktur: 

MessageClass - Message->Class; 

MessageCode = Message->Code; 
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Wir können dann anhand von MessageClass feststellen, welches 
IDCMP-Flag die Nachricht ausgelöst hat. In diesem Sinne müs¬ 
sen wir dann die Untersuchungen fortsetzen. Es ist aber auch 
sehr wichtig, nicht zu vergessen, auf die Nachricht zu antwor¬ 
ten, damit das Nachrichten-System weiterlaufen kann. Denn 
ohne Antwort können keine weiteren Nachrichten empfangen 
werden! 

ReplyMsg(Message); 

Machen wir uns jetzt daran, für die einzelnen Flag-Gruppen 
Abfragen zu konstruieren, mit denen wir die Datenflut bewälti¬ 
gen können. 


3.7.2.1 Die altbekannten Gadgets 

Wenn wir erstmal den Zeiger auf die IntuiMessage-Struktur ha¬ 
ben, können wir mit der Auswertung beginnen. Zuerst sehen wir 
uns an, wie man diese für Gadgets programmiert. Sie haben 
dazu zwar schon im Verlauf der Intuition-Kapitels einiges lesen 
können, doch hier erfahren Sie, wie man von Grund auf eine 
Gadget-Abfrage entwickelt und seinen eigenen Bedürfnissen an¬ 
paßt. 

Zuerst testen wir, ob es sich um die Gadget-IDCMP-Flags han¬ 
delt: 


if (MessageClass & (GADGETDOUN j GAOGETUP)) 

/* Gadget-Abfrage V 

> 

Dann besorgen wir uns den Zeiger auf die Gadget-Struktur: 

struct Gadget *GadgetPtr; 

GadgetPtr * (struct Gadget *) Message->IAddress; 

Für die Unterscheidung mehrerer Gadgets brauchen wir jetzt 
noch die GadgetID: 

USHORT GadgetID; 

GadgetlD - GadgetPtr->GadgetID; 
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(Ich empfehle fortlaufende Nummern, die am Anfang des Pro¬ 
gramms durch DEFINES ersetzt werden, um die Gadgets 
namentlich leichter erkennen zu können.) 

Nach GadgetID unterschieden, können zum Schluß die einzelnen 
Aktionen ausgelöst werden. Am übersichtlichsten gestalten Sie 
Ihren Programmtext, wenn Sie vom Programmtext längere Reak¬ 
tionen in einer Funktion ablegen: 

switch(GadgetlD) 

case TEXTGADGET : Text_Auswerten(); 
break; 

case SCHIEBER : Neue_Uerte(); 

break; 


case .... 

> 

Alle weiteren Informationen kann sich das Programm über den 
Pointer auf die Gadget-Struktur holen. In der IntuiMessage- 
Struktur wird bei Gadgets nichts weiter abgelegt, es sei denn. 
Sie interessieren sich für die Mauskoordinaten. Diese sind natür¬ 
lich immer dort zu finden. Die Abfrage ist ganz einfach: 

MausX s (SHORT) Message->MouseX; 

MausY » (SHORT) Hessage->MouseY; 

Denken Sie aber daran, daß die Koordinaten-Angaben relativ 
zum Window zu interpretieren sind. 


3.7.2.2 Das Window macht Meldungl 

Anders als bei den Gadgets läuft die Abfrage der Window-Flags. 
Sie sind nicht allgemein und müssen auch nicht weiter erforscht 
werden. Window-Flags geben sofort über einen bestimmten Zu¬ 
stand Auskunft! 

Dafür bieten sich zwei Abfragemöglichkeiten an: Die erste fügt 
sich in das System ein. Zuerst selektieren wir alle Window-Flags 
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heraus und untersuchen anschließend weiter. E>as läßt sich auf 
einfache Weise realisieren: 

if (MessageClass & (NEUSIZE | REFRESHWINDOU j ACTIVATEUINDOU j 

INACTIVATEUINDOU)) 

{ 

UlndowPtr = (struct Window *) Message->IAddress; 
switch(MessageClass) 

C 

case NEUSIZE : Breite = UindowPrt->Uidth; 

Hoehe = WindowPrt->Height; 
break; 

case REFRESHWINDOU : 

break; 

case ACTIVATEUINDOU : 

break; 

case INACTIVATEUINDOU: ActivateUindow(UindowPtr); 
break; 


> 


Programmteil 3.10: Window-Nachrichten-Abfrage 

Bitte beachten Sie, daß wir natürlich nicht das Flag SIZEVE- 
RIFY auf diese Art abfragen können, da vor der genaueren 
Untersuchung schon mit ReplyMsgO auf die Nachricht geant¬ 
wortet wird. Hier reicht aber eine einfache Abfrage des Flags 
vor jeder Antwort auf die Nachricht. Sie können dann einfach 
die ReplyMsgO-Funktion überspringen. 

Ein witziger Trick wurde in der letzten Überprüfung verwendet. 
Das Window unseres Programms wird durch diese Zeilen immer 
wieder aktiviert. Sobald der Benutzer irgendein anderes Window 
anklickt, wird sofort wieder unseres aktiviert. 

Auch die Workbench benutzt diese Methode! Wenn Sie einen 
File-Namen ändern, dann wird ein Fenster mit einem String- 
Gadget geöffnet. Das Fenster hat die Größe des Gadgets und ist 
ohne jede System-Grafik. Klicken Sie jetzt irgendwo in die 
Workbench, wird das Rename-Window sofort wieder aktiviert. 
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3.7.2.3 Requester werfen den Ablaufplan über den Haufen 

E>as ist in der normalen Programmierung nicht der Fall. Reque¬ 
ster können nur vom Programm ausgelöst werden und somit 
nicht den Ablaufplan gefährden. Es sei denn. Sie bieten dem 
Benutzer den Komfort, daß er über den DMRequest jederzeit 
eine bestimmte Funktion aufrufen kann. Dann ist der Zeitpunkt 
der Unterbrechung natürlich nicht festgelegt. Dafür sind haupt¬ 
sächlich die Requester-Flags gedacht. 

Setzen Sie im IDCMP des Windows REQSET und REQCLEAR, 
und Sie erhalten immer Nachricht, wenn der erste Requester ak¬ 
tiviert wird - unser DMRequest - und wenn der letzte Requester 
verschwindet - auch unser DMRequest. 

Da das End-Flag sowieso über die Requester-Routine bearbeitet 
wird, brauchen wir uns im Hauptprogramm nur um REQSET 
kümmern. Dazu ist nur eine Zeile notwendig: 

if (MessageClass & REQSET) DMRequest_Auswertung(); 

Über REQVERIFY können Sie, genau wie bei SIZEVERIFY, 
bestimmen, ob der Prozeß sofort ausgelöst werden soll oder vor¬ 
her noch wichtige Arbeiten zu erledigen sind. Wenn das Flag 
gesetzt ist, erhält das Programm schon diese Nachricht, bevor 
Intuition den Requester öffnet. Dieser kann nämlich erst bear¬ 
beitet werden, nachdem auf die Nachricht mit ReplyMsgO 
geantwortet wurde. 


3.7.2.4 Menü-Flags mit Auswertung 

Menüs sind neben den Gadgets die wichtigste Eingabemöglich¬ 
keit für den Anwender, die Intuition bietet. Auch sie erfordern 
eine Auswertung. 

Ist vom Benutzer die Menütaste gedrückt und wieder losgelassen 
worden, erhält das Programm über den IDCMP eine Nachricht, 
wenn das MENUPICK-Flag gesetzt wurde. Wir können dann im 
Feld Code der IntuiMessage-Struktur nach der Nummer des 
Menüpunktes suchen. Nun werden die Menüpunkte für den Be- 
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diener offensichtlich nicht mit Nummern verwaltet. Aber intern 
wurde ein System entwickelt, um die Identifizierung möglichst 
einfach zu halten. Allerdings liegt in dem System auch der 
Grund, warum wir nur eine Stufe Untermenüs programmieren 
können, obwohl doch eine unendliche Verschachtelung denkbar 
wäre. 

Sehen wir uns nun die Kodierung der ausgewählten Menüs an! 
Die beiden Bytes sind wie folgt "verschlüsselt": 

UUUUU MMM|MMN NNNNN 

Wir haben zwei Bytes in drei Bit-Gruppen. Die erste NNNNN 
beschreibt die Menü-Nummer. Wir müssen diese nur von den 
anderen befreien, und schon sind wir im Besitz der Zahl. Diese 
Arbeit erledigt die Definition MENUNUM(Code). Sie ist im 
<intuition/intuition.h>-Include-File zusammen mit den folgen¬ 
den zu finden und klammert einfach die entsprechenden Bits 
aus. 

Die zweite Gruppe, MMMMMM, stellt die Nummer des Menü¬ 
punktes dar. Sie wurde doppelt so groß gewählt, damit auch 
wirklich genügend Menüs (31) und genügend Menüpunkte (63) 
benutzt werden können. Möchten Sie auch die Nummer des 
Menüpunktes feststellen, dann verwenden Sie dazu die Defini¬ 
tion ITEMNUM(Code). 

In der dritten Gruppe, UUUUU, finden Sie die Nummer des 
Untermenüpunktes, wenn überhaupt einer vorhanden ist. Auch 
hier sind wieder 31 Werte möglich. Diesen Wert erreichen Sie 
über die Definition SUBITEM(Code). 

Durch die Definitionen wird uns die Menüabfrage wirklich ein¬ 
fach gemacht. In unserer Abfrageschleife für alle IDCMP- 
Nachrichten müssen wir zuerst feststellen, ob überhaupt eine 
Menü-Nachricht vorliegt. Dann können wir zu einer Funktion 
verzweigen, die weitere Auswertungen vornimmt. 

if (NessageClass & NENUPICK) Nenu_Auswertung(Code); 
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In der Funktion werden schließlich die Werte berechnet und 
nacheinander ausgewertet: 


Meruj_Auswer t ung (HenurHjmmern) 

USHORT Menununnmer; 

C 

USHORT Menu, Henultem, Subltem; 

Menu = MENUNUMCMenununmern); 
Menultem = ITEMNUM(Menununinern); 
Subltem = SUBITEMCMenunummern); 


switch(Menu) 
t 

case FILEMENU : FileAusuertung(MenuItem, Subltem); 
break; 


case WORKMENU 


> 


> 


WorkAuswertung(MenuItem); 
break; 


FileAuswertung(MenuItem, Subltem) 

USHORT Menultem, Subltem; 
i 

switch(MenuItem) 

case LADEN : LadenO; 

break; 

case SPEICHERN: SpeichernO; 

break; 

case LOESCHEN : switch(Subltem) 
i 

case FILE : DelFileO; 
break; 

case TEXT : DelTextO; 
break; 

> 

break; 

> 


UorkAuswertung(MenuItem) 
USHORT Menultem; 
i 

8witch(MenuItem) 

i 


case MARKIEREN: Markt) 
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break; 

case EDITIEREN: EditO; 

break; 


case SUCHEN 


> 


: SuchenO; 
break; 


Funktion 3.7: Menu-Abfrage 


Ich habe anstatt der Nummern für die Menüs, Menüpunkte und 
Untermenüs definierte Ausdrücke gewählt. Dadurch wird der 
Programmtext leichter verständlich. Hier sind die DEFINES für 
die obigen Routinen: 

/* Menünamen */ 

«define FILEMENU 
«define UORKMENU 

/* 1. Menü FILEMENU */ 

#define LADEN 
#define SPEICHERN 
#define LOESCHEN 

/* Untermenü LOESCHEN */ 

#define FILE 
«define TEXT 

/* 2, Menü WORKMENU */ 

«define MARKIEREN 
«define EDITIEREN 
«define SUCHEN 


3.7.2.S Mäuse laufen gerne. Aber wohin? 

Nicht nur zum Auslösen von Gadgets und Markieren von Menü¬ 
punkten ist die Maus geschaffen. Der Programmierer kann alle 
Tätigkeiten eigenständig abfragen. Für die direkte Mausabfrage 
wird auch der IDCMP genutzt. Wir kennzeichnen hier durch 
Setzen der Flags, ob wir über das Drücken oder Loslassen der 
Maus-Buttons informiert werden möchten oder lieber über die 
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Bewegung der Maus. Alles das kann über den IDCMP emp¬ 
fangen werden. 

In einem Zeichenprogramm kann es durchaus wichtig sein zu 
wissen, wann der Mausknopf gedrückt wird, damit darauf z.B. 
an der Stelle ein Punkt gesetzt wird. Allerdings gibt es zwei 
Maus-Buttons, und bei beiden kann sowohl das Niederdrücken 
als auch das Loslassen abgefragt werden. Dementsprechend gibt 
es vier Ergebnisse: 

SELECTDOWN, SELECTUP 

Die "select"-Flags stehen für die linke Maustaste. 

MENUDOWN, MENUUP 

Die "menu"-Flags stehen für die rechte Maustaste. 

Beachten Sie aber, daß die linke Maustaste nur Signale sendet, 
wenn sie nicht für die Arbeit mit Gadgets gebraucht wird. De¬ 
ren Handhabung hat eine höhere Priorität! Gleiches gilt für die 
rechte Maustaste. Wird sie für die Menüauswahl benötigt, dann 
erfährt das Programm überhaupt nichts davon. Nur wenn extra 
das Flag RMBTRAP gesetzt wurde, ist die rechte Maustaste re¬ 
gistrierbar. Darauf sollten Sie achten! 

Die Abfrage sieht im Programm sehr einfach aus. Nehmen wir 
an, daß das Programm beide Tasten benötigt und keine Menüs 
verwaltet. Wir setzen also im Window das IDCMP-Flag MOU- 
SEBUTTONS und RMBTRAP. Immer, wenn wir eine Nachricht 
erhalten, finden wir im Code-Feld der IntuiMessage-Struktur 
die Art des Maus-Buttons: 

MausX = (SHORT) Message->MouseX; 

MausY = (SHORT) Message->MouseY; 

if (MessageClass & MCXJSEBUTTONS) MausAbfrage(Code, MausX, MausY); 

Diese Zeile verzweigt in ein Unterprogramm, in dem weitere 
Auswertungen stattfinden: 
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MausAbfrageCFlag, MausX, MausY) 

USHORT Flag; 

SHORT MausX, HausY; 

C 

switch(Flag) 

i 

case SELECTDOWN : Begin_Line(HausX, HausY); 
break; 

case SELECTUP : End_Line(MausX, HausY); 
break; 

case MENUDOWN : Begin_Erase(MausX, MausY); 
break; 


case MENUUP 


> 


> 


End_Erase(MausX, MausY); 
break; 


Funktion 3.8: Maus-Abfrage 


Die Beispiel-Funktion bekommt als Übergabe werte den Status 
der Maus, zusammen mit den Koordinaten. Je nachdem, welcher 
Maus-Status gerade herrscht, wird entweder die Linien-Funktion 
des Programms auf gerufen und gestartet oder beendet. Oder aber 
die Flächen-Lösch-Funktion tritt in Aktion, und wir übergeben 
den ersten Eckpunkt oder den zweiten. 

Der nächste äußerst wichtige Punkt der Mausabfrage ist die Po¬ 
sitionsübermittlung. In dem ersten Beispiel haben wir diese 
schon teilweise benutzt, denn zu jeder IntuiMessage wird ja 
auch die Mausposition relativ zum Fenster geliefert. Wollen wir 
aber z.B. eine ständige Koordinatenanzeige programmieren, so 
können wir nicht darauf warten, daß der Benutzer immer eine 
Taste drückt, wenn er die Koordinaten sehen möchte. Für ihn ist 
es entscheidend, immer den aktuellen Stand zu haben. Auch 
dafür bietet Intuition einen Nachrichten-Typ. Setzen Sie einfach 
das IDCMP-Flag REPORTMOUSE, und Sie empfangen jede 
kleine Bewegung! 

Hinweis: An dieser Stelle möchte ich Sie schon warnen! Auch 

das Bewegen der Maus um nur einen Pixel löst schon 
eine Nachricht aus. Das kommt sehr oft vor! Beden¬ 
ken Sie auch, daß für das genaue Positionieren meist 
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sehr viele Schritte notwendig sind, bei denen Ihr 
Programm einen "Infarkt" erleiden kann. 

Auch bei den Mausbewegungen empfehle ich eine normale Ab¬ 
frage: 


MausX = (SHORT) Message-»MouseX; 

MausY s (SH(XIT) Message->MouseY; 

if (MessageClass & M(XJSEMOVE) MausBewegungCMausX, MausY); 

Ein Unterprogramm kann dann die Auswertung vornehmen. Mit 
der oben beschriebenen Methode erhalten Sie bei jeder Mausbe¬ 
wegung die absoluten Werte relativ zum Fenster (les IDCMP. In 
manchen Anwendungen ist es aber einfacher, wenn man nur den 
Unterschied zu letzten Position erfährt. 

Für diese Umstellung müssen Sie nur das DELTAMOVE-Flag 
setzen. 


3.7.2.6 Erkennunng der Tastatureingaben 

Wir erkennen Tastatureingaben nur, wenn eins der beiden Flags 
VANILLAKEY oder RAWKEY gesetzt ist. 

Damit stellen wir den Modus ein, unter dem wir die Tastatur- 
Codes erhalten wollen. Es ist nur ein Modus pro Window mög¬ 
lich. 

RAWKEY unterscheidet sich von VANILLAKEY dadurch, daß 
wir bei RAWKEY "unübersetzte" Codes erhalten. Das heißt, wir 
bekommen für jede Taste eine Nummer als Nachricht. 

Ist VANILLAKEY aktiv, werden die Tastaturnummern nach der 
Tastaturtabelle übersetzt. Wir erhalten dann die Zeichen der Ta¬ 
staturtabelle. 

Somit richtet sich das Programm nach der Tastaturbelegung des 
jeweiligen Computers. In Deutschland verwenden wir eine 
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deutsche Tastaturbelegung, in England eine englische, in 
Frankreich eine französische usw... 






Abbildung 3.12: RAW-Tastatur~Codes I 

Sie sehen anhand der Abbildung die Tastatur-Codes für jede 
einzelne Taste. (Die Tastatur wurde aus Platzgründen in der Ab¬ 
bildung aufgeteilt.) Zu beachten ist, daß selbst der Zehnerblock 
eine eigene Numerierung besitzt. Wollen Sie eine Abfrage pro¬ 
grammieren, dann müssen Sie im C/a^s-Feld nach dem Flag 
RAWKEY suchen und im Feld Code nach der Tastennummer. 
Zusätzlich finden Sie im Feld Qualifier einen Statusbericht der 
Sondertasten wie Shift, Alt, Ctrl usw. 

Sie können mit dieser Tabelle gedrückte Tasten identifizieren: 
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QUALIHER TYPES 

Hex-Wert 

IEQUALIFIER_LSHIFT 

IEQUALIFIER_RSHIFT 

lEQUALIFIER^CAPSLOCK 

0x0001L 
OxOOOZL 
OxOOOAL 

IEQUALIFIER_CONTROL 

OxOOOSL 

lEQUALIFIER^LALT 

IEQUALIFIER__RALT 

0x001OL 
0x0020L 

IEQUALIFIER__LCOMMAND 

IEQUALIFIER_RCOMMAND 

OxOOAOL 

OxOOSOL 

IEQUALIFIER^NUMERICPAO 

0x01OOL 

IEQUALIFIER_^REPEAT 

0X0200L 

lEQUALIFIER^INTERRUPT 

OxOAOOL 

IEQUALIFIER^MULTIBROADCAST 

OxOSOOL 

lEQUALIFIER^MIDBUTTON 

iequalifier’rbutton 

lEQUALIFIER^LEFTBUTTON 

OxIOOOL 

0X2000L 

OxAOOOL 

I EQUAL IFI ER_,RELAT IVEMOUSE 

OxSOOOL 

Tabelle 3.20: Qualifier-Typen 



Das Input-Device läßt selbst eine Unterscheidung in den Tasten¬ 
gruppen zu. So können Sie die linke, rechte und auch die Caps- 
Shift-Taste erkennen. Weiterhin erfahren wir etwas darüber, ob 
die Information vom Numericpad kam und ob sich die Taste 
schon im Repeat-Status befindet. Sie können hierüber sogar die 
Maustasten abfragen. 

Wollen Sie doch lieber mit Codes arbeiten, die schon nach der 
Tastaturtabelle verarbeitet sind, dann erhalten Sie bei Class eine 
Nachricht des Types VANILLAKEY. Unter Code finden wir 
den übersetzten Zeichen-Code. Diese Möglichkeit ist die ein¬ 
fachste. Egal, welche Methode Ihnen in einem Programm besser 
gefällt, der Aufruf ähnelt den bereits bekannten: 
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if (MessageClass & RAWKEY) RAW_Auswertung(Code, Qualifier); 
if (MessageClass & VANILLAKEY) VANILLA__Auswertung((char)Cocle); 

Entscheidende Unterschiede werden erst in der Auswertung des 
empfangenen Codes sichtbar. Während VANILLAKEY ganz 
einfach mit dem Zeichen arbeiten kann, muß die RAWKEY- 
Auswertung erst einmal eine eigene Tastaturtabelle bemühen. 

VAN I LLA__Auswertung( Zei eben) 
char Zeichen; 
i 

Print(Zeichen); 

InputTextBuffer(Zeichen); 


> 

Funktion 3.9: Vanilla-Auswertung 

RAU Auswertung(Code, Qualifier); 

USHORT Code, Qualifier; 

< 

/* 1. Umwandlung nach Tabelle V 

Zeichen = TastTabCQualifier][Code]; 

/* oder 2. Umwandlung mit Einzelunterscheidung V 

switch(Qualifier) 

case lEQUALIFIER^LSHIFT : 
switch(Code) 

< 

/* Auswertung linke Shift-Taste V 

> 

break; 

case IEQUALIFIER_RSHIFT : 
switch(Code) 
i 

/* Auswertung rechte Shift-Taste */ 

> 

break; 

switch(Code) 

i 

/* Auswertung ohne Shift-Taste V 

> 

> 

> 


Funktion 3.10: RawKey-Auswertung 
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3.7.2.7 Die Diskettenstation 

Ich möchte an dieser Stelle noch einmal auf die File-Select-Box 
zurückkommen. Diese soll ja das Inhaltsverzeichnis der einge¬ 
legten Diskette anzeigen. 

Was passiert nun, wenn wir die Diskette aus dem Laufwerk 
nehmen und sie wechseln? 

Nichts! Immer noch die gleiche Anzeige mit den gleichen Files, 
aber eigentlich sollte doch das Verzeichnis der neuen Diskette 
angezeigt werden. 

Dieses Problem läßt sich einfach über die beiden Disk-Flags lö¬ 
sen. Mit dem ersten, DISKREMOVED, erfahren wir immer, 
wenn eine Diskette entfernt wird. Dann kann gegebenenfalls die 
File-Tabelle gelöscht werden. 

Mit DISKINSERTED können wir den Lesevorgang starten, der 
das neue Verzeichnis analysiert. 

if (MessageClass & DISKREMOVED) 

< 

/* Tabelle löschen V 

> 

if (MessageClass & DISKINSERTED) 

C 

Tabelle neu einiesen V 

> 

3.8 Menüs, die Auswahl der Konsumgesellschaft 

Wie ist das bei Ihnen? Sie haben ein Programm geschrieben, das 
mit vielen, vielen Funktionen auf wartet. Zu jeder Kleinigkeit 
haben Sie ein Unterprogramm geschrieben. 

Der Benutzer wird überflutet mit Auswahlmöglichkeiten. Nur ... 

... wissen Sie noch nicht, wie Sie ihm alle Funktionen darbieten 
sollen. Nehmen wir Tastaturbelegungen, dann heißt es eine 
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Schablone anzufertigen, denn auswendig lernen dauert lange, 
und man ist ja so vergeßlich. 

Warum nicht Gadgets? Wir können ja nicht den ganzen Bild¬ 
schirm mit Gadgets vollpacken. Immerhin haben wir auch noch 
ein Ein- und Ausgabe-Window. Wohin dann mit den Funktio¬ 
nen? (Hätten Sie bloß nicht so viele programmiert!) 

Dem Amiga macht das gar nichts aus! Er hat für jede Menge an 
Auswahlpunkten das richtige Medium! Gadgets eignen sich gut 
für einige kleine Aufrufe, und wenn gleich in "Zehnersalven" 
gearbeitet wird, nehmen wir die Menüs. 

Mit den von Intuition angebotenen Menüs können wir alle 
Funktionen unseres Programms in Gruppen unterteilen. Da gibt 
es dann meist eine Gruppe für "Datei", "Bearbeiten". In jeder 
dieser Gruppen finden wir Funktionen zu einem Thema. Manche 
Funktionen sind noch weiter untergliedert, und wir können dann 
aus wählen. 

Die kleinsten, aber auch ersten Menüs, die Sie als Amiga-Besit- 
zer kennengelernt haben, sind die Workbench-Menüs. Wir finden 
drei Hauptgruppen vor: "Workbench", "Disk" und "Special". Jede 
dieser Hauptgruppen enthält Unterpunkte, die bei Auswahl eine 
Aktion auslösen. So etwas wollen wir jetzt auch programmieren! 
Wir wollen ein oder mehrere Menüs schreiben, die mehrere 
Menüpunkte haben. Manche der Menüpunkte sollen auch noch 
Untermenüs besitzen, in denen man weitere Punkte findet. Die¬ 
ses Menü soll alle Möglichkeiten ausnutzen, die programmier¬ 
technisch möglich sind. Lassen Sie sich überraschen, denn es ist 
weit mehr erlaubt, als Sie von der Workbench kennen. 


3.8.1 Der allgemeine Aufbau eines Menüs 

Es ist wichtig zu wissen, welchen Aufbau die Menüs haben, da¬ 
mit wir unsere gestalterischen Grenzen kennenlernen. Nehmen 
wir als erstes Beispiel, weil es jedermann zugänglich ist, die 
Workbench-Menüs. 
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Wenn die rechte Maustaste gedrückt ist, erkennt man, daß die 
Titelleiste des Screens für eine neue Leiste weichen muß, in der 
wir drei Namen finden. Dies sind die Namen der Funktions¬ 
gruppen der drei Menüs. Die Leiste selbst paßt sich dem Font 
des jeweiligen Screens an. Den Überschriftentext können wir als 
Programmierer pixelgenau in X-Richtung einsteilen. 

Betrachten wir nun das erste Menü: Das Workbench-Menü hat 
sechs Funktionen, die alle nicht anwählbar sind. Alle Texte wer¬ 
den dafür in der sog. Geisterschrift dargestellt (engl, ghosted). 
Erst wenn wir z.B. ein Icon anklicken, ist entsprechend der 
Möglichkeiten eine Auswahl zugelassen. Gleiches gilt für die 
beiden anderen Menüs. 

Als zweites Beispiel möchte ich die Menüleiste eines Zeichen¬ 
programms benutzen. Dieses Menü benutzt auch Grafikelemente. 
Wir können deshalb als ersten Punkt festhalten, daß Menüs nicht 
unbedingt aus Textzeilen bestehen müssen. Wir können überall 
Grafiken verwenden. Die zweite Besonderheit ist, daß wir zu¬ 
sätzlich nicht daran gebunden sind, in einer "Zeile" einen Text 
oder eine Grafik zu verwenden. Es ist uns freigestellt, wie viele 
Texte oder Grafiken pro Zeile in einem Menü stehen. Aber 
achten Sie als Programmierer darauf, daß sich die einzelnen 
Punkte nicht überlappen! 

Drittens möchte ich die freie Wahl vorstellen, mit der Sie über 
die Größe des Menükastens bestimmen. Es liegt ganz an Ihnen, 
ob wir ein Menü haben, das vielleicht nur zwei Zeichen breit 
ist, oder eines, das den ganzen Screen ausfüllt. Die Größe wird 
automatisch den Menüpunkten angepaßt. 


3.8.2 Wir basteln ein Menü 

Sie haben jetzt einen groben Überblick durch die beiden Bei¬ 
spiele gewonnen. Es sollte unser erstes Ziel sein, eine eigene 
Menüleiste aufzubauen. Um möglichst freie Gestaltungsmöglich¬ 
keiten zu haben, möchte ich dazu einen neuen Screen mit eige¬ 
nen Parametern öffnen. Außerdem benötigen wir ein Window, 
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ohne das keine Menüleiste existieren kann, denn sie wird an das 
Window angeheftet. 


Das folgende Listing entspricht dem Standardprogramm für 
Screens und enthält zusätzlich noch eine Zeichensatzeinstellung: 


^*************4r************************* 
★ ★ 

* Programm: Demonstrations Menu-Strip * 

* 

* Autor: 

★ _ 

* Wgb 

* 


Datum: 

13. 1.1988 


Kommentar: 
Menu-Strip 


***************************************^ 


#include <exec/types.h> 

#include <intuition/intuition.h> 


struct IntuitionBase *IntuitionBase; 
struct Screen ♦FirstScreen; 

struct Window *FirstWindow; 

struct IntuiMessage *message; 


struct TextAttr ScreenFont = 
C 

(STRPTR)'*topaz.font**, 
TOPAZ SIXTY, 

FS NORMAL, 

FPF_R0MF0NT 

>; 


struct NewScreen FirstNewScreen = 
i 


o 

o 

/* LeftEdge, TopEdge 

*/ 

640, 256, 

/* Width, Height 


3, 

/* Depth 

*/ 

0, 1, 

/* DetailPen, BlockPen */ 

HIRES, 

/* ViewModes 

*/ 

CUSTOMSCREEN, 

/* Type 

*/ 

ÄScreenFont, 

/* Font 

*/ 

(UBYTE ♦)''Screen Test", 
NULL, 

/* Gadgets 

*/ 

NULL 

/* CustomBitMap 

*/ 


>; 
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struct NewWindow FirstNewWindow = 


o 

o 

/* LeftEdge, TopEdge 


640, 100, 

/* Width, Height 

*/ 

0, 1, 

/* DetailPen, BlockPen 

*/ 

CLOSEWINDOW, 

/* IDCMP Flags 

*/ 

WINDOWDEPTH j 

/* Flags 

*/ 

WINDOWSIZING 1 



WINDOWDRAG | 



WINDOUCLOSE j 



SMART REFRESH, 



NULL," 

/* First Gadget 

*/ 

NULL, 

/* CheckMark 

*/ 

(UBYTE *)"Test 

Menü-Strip”, 


NULL, 

/* Screen (kommt noch) */ 

NULL, 

/* BitMap 

*/ 

100, 50, 

/* Min Uidth, Height 

*/ 

640, 256, 

/* Max Uidth, Height 

*/ 

CUSTOMSCREEN 

/* Type 

*/ 


>; 


mainO 

ULONG MessageClass; 

USHORT Code; 

struct Message *GetMsg(); 

Open_AU(); 

FOREVER 

if ((message = (struct IntuiMessage *) 

GetMsg(FirstWindow->UserPort)) == NULL) 

WaitdL « FirstWindow->UserPort->mp_SigBit); 
continue; 

> 

MessageClass = message*>Class; 

Code = message->Code; 

ReplyMsgCmessage); 
switch (MessageClass) 

C 

case CLOSEUINDOU : Close_All(); 

exit(TRUE); 

break; 

> 

> 

> 

> 
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y*********************************************** 
* * 

* Funktion: Library, Screen und Window öffnen * 

* * 

* Autor: Datum: Kommentar: * 

♦ _ _ _ ♦ 

* Wgb 16-10-1987 funktioniert! * 


* * 
*********************************************** j 


Open Allo 

c 

void *OpenLibrary(); 

struct Window *OpenWindowO; 
struct Screen *OpenScreen(); 

if (KlntuitionBase = (struct IntuitionBase *) 
OpenLibrary('*intuition -library“, OL))) 

< 

printfC'Keine Intuition Library gefunden!\n"); 

Close AllO; 

exit(FALSE); 

> 

if (!(FirstScreen = (struct Screen *) 
OpenScreen(&FirstNewScreen))) 

printf("Screen hat keine Zeit!\n"); 

Close_All(); 

exit(FALSE); 

> 

FirstNewWindow-Screen = FirstScreen; 

if (!(Firstwindow = (struct Window *) 

OpenWindow(&FirstNewWindow))) 

printfC'Window will nicht aufgehen!\n*'); 

Close AllO; 
exit(FALSE); 

> 

> 
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^********4r****************************** 

* * 

* Funktion: Alles Geöffnete schließen * 

* sssssssssssssssssssssssssssssssssss * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ ★ 

* Wgb 16.10.1987 Window, Screen * 

* und Intuition ♦ 

* * 

***************************************^ 


Close AHO 
i “ 

if (FirstUindow) 
if (FirstScreen) 
if (IntuitionBase) 
> 


CloseWindow(Firstwindow); 

CloseScreen(FirstScreen); 

CloseLibrary(IntuitionBase); 


Programm 3.9: Menu-Strip-Demo 


3.8.2.1 Die Menüleiste als Grundstock 


Mit Hilfe dieses Testprogramms werden wir nun die Menüleiste 
aufbauen. Der englische Fachbegriff für Menüleiste ist übrigens 
Menu-Strip. Dafür benötigen wir zuerst wieder eine Struktur für 
jedes Menü. Diese enthält neben dem Namen des Menüs noch 
ein Flag, Koordinatenangaben und zwei Link-Pointer. 


struct Menu 
{ 

0x00 00 struct Menu *NextMenu; 

0x04 04 SHORT LeftEdge; 

0x06 06 SHORT TopEdge; 

0x08 08 SHORT Uidth; 

OxOA 10 SHORT Helght; 

OxOC 12 USHORT Flags; 

OxOE 14 BYTE *MenuNaine; 

0x12 18 struct Menultem *FirstItem; 

0x16 22 SHORT JazzX; 

0x18 24 SHORT JazzY; 

OxIA 26 SHORT BeatX; 

OxIC 28 SHORT BeatY; 

OxIE 

>; 
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Strukturbeschreibung 

*NextMenu 

Zuerst enthält die Menu-Struktur, wie so viele Intuition-Struk¬ 
turen, einen Zeiger auf eine Folgestruktur. Er wird für die Ver¬ 
kettung mehrerer Menüs benötigt. 

LeftEdge, Width 

Die Werte beschreiben die Position und die Breite der Select- 
Box. Das ist der Bereich, in den der Mauspfeil gefahren werden 
muß, bis das Menü aktiviert wird. 

TopEdge, Height 

Leider werden diese beiden Werte nicht genutzt. Sie wurden le¬ 
diglich implementiert, um auch für Erweiterungen zur Verfü¬ 
gung zu stehen. So soll es später möglich sein, auch Grafiken in 
die Menu-Strip einzubinden, was momentan noch nicht erlaubt 
ist. 

Flags 

Ein Flag-Wert, über den wir einstellen, ob das gesamte Menü 
anwählbar sein soll oder nicht. Dann werden nämlich alle Menü¬ 
punkte "ghosted" ausgegeben. Um die Auswahl zuzulassen, ist 
das Flag MENUENABLED zu setzen. Das Flag MIDRAWN wird 
von Intuition gesetzt, wenn das Menü gerade vom Benutzer aus¬ 
gewählt wurde. 

*MenuName 

Als nächstes finden wir einen Pointer auf den Namen des 
Menüs. Hier ist nur ein String erlaubt, der im Default-Zeichen¬ 
satz des Screens ausgegeben wird. 

*FirstItem 

Hier finden wir die Verkettung mit einer weiteren Struktur. Sie 
enthält alle Informationen für die einzelnen Menüpunkte. 

Alle weiteren Variablen werden von Intuition benutzt und müs¬ 
sen nicht initialisiert werden. 
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Für den Anfang bauen wir drei Menüs in unser Testprogramm 
ein. Das erste soll alle Disketten-Funktionen unterstützen und 
heißt "Datei". Sie können es fast in jedem Programm verwenden, 
denn die Arbeit mit der Diskette ist für gute Programme not¬ 
wendig. Das zweite Menü schlägt schon einen spezielleren Weg 
ein. Es ist für eine Textverarbeitung gedacht. Sie sollen in ihm 
Einstellungen für das Textaussehen machen können. Es wird 
"Design" heißen. Im dritten Menü werden wir uns den Grafik- 
Programmen widmen. Hier können Sie sich den Zeichenstift 
aussuchen oder die Zeichenfarbe wählen. Es heißt "Grafik". 


Ich habe alle drei Strukturen initialisiert vorbereitet. Sie brau¬ 
chen sie nur noch abzutippen und in das Testprogramm einzu¬ 
bauen. 


struct Menu Grafik = 

< 

NULL, 

220 , 0 , 

70, 10, 

HENUENABLED, 

(UBYTE "Grafik”, 
NULL 


struct Menu Design = 

C 

&Grafik, 

100 , 0 , 

70, 10, 

MENUENABLED, 

(UBYTE *) "Design", 
NULL 


struct Menu Datei = 
i 


&Design, 

10 , 0 , 

60, 10, 
MENUENABLED, 

(UBYTE *> "Datei", 
NULL 


>; 


Struktur 3.19: Menu-Strukturen zum Denur-Programm 
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Fügen Sie nun zwei neue Befehle in unsere _All()-Funktionen 
ein. Zuerst müssen wir diese Menü-Leiste in das Window ein¬ 
binden. Dafür gibt es die Intuition-Funktion SetMenuStrip(). Sie 
hat folgendes Aussehen: 

Success = SetMenuStriptUindou, Nenu); 

DO -264 AO AI 

Wir übergeben das Window und die Adresse der ersten Menu- 
Struktur. Schon ist die Menü-Leiste aktiv. Sie können mit ihr 
arbeiten, wann immer das Window aktiv ist. Für unsere 
Open_All()-Funktion bedeutet das, daß Sie diese Zeile nach der 
OpenWindow()-Funktion ergänzen müssen: 

SetMenuStrip(FirstUindou, &Datei); 

Ich habe hier mit Absicht den Rückgabewert Success nicht be¬ 
achtet, da er sowieso immer TRUE lautet. Wir ersparen uns da¬ 
durch eine Variablendefinition. 

In der Close_All()-Funktion hieße die Ergänzung dann: 

if (FirstUindow) ClearNenuStrip(FirstUindow); 

Das allgemeine Format von ClearMenuStripO ist: 

Cl ea r MenuS t r i p(Window); 

-54 AO 

Denken Sie daran, daß die Menü-Leiste entfernt werden muß, 
bevor das Window geschlossen wird, da es sonst zu einem Sy¬ 
stemabsturz kommt. Außerdem ist die Menüleiste vor jeder Än¬ 
derung zuerst vom Window zu entfernen. Nach der Änderung 
kann sie dann wieder mit SetMenuStrip() angehängt werden. 

Programmbeschreibung 

Nach dem Start des Programms sehen Sie einen Screen mit einem 
Window. Solange das Window inaktiv ist, können Sie über die 
rechte Maustaste, die Menütaste, keine Menüleiste erreichen. 
Erst nachdem das Fenster aktiviert wurde, ist auch die Menülei¬ 
ste sichtbar. Sie finden dort drei Menüs mit den definierten Ti¬ 
teln vor, die aber noch überhaupt keine Punkte beinhalten. Das 
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soll sich gleich ändern! Zuvor sei noch erwähnt, daß Sie das 
Programm über das Close-Gadget des Windows beenden. 


3.8.2.2 Die ersten Menüpunkte und die Menultem-Struktur 

Als zweites Ziel wollen wir uns den Entwurf der ersten Menü¬ 
punkte setzen. Wie greifen dabei zuerst auf Texte zurück, weil 
deren Handhabung besonders einfach ist. Wir benötigen lediglich 
für jeden Text eine IntuiText-Struktur. Das dürfte aber nicht 
weiter schwierig sein. Hier sind die von mir geplanten Menü- 
punkt-Texte: 

struct TextAttr Font = 

< 

(STRPTR)"topaz.font", 

TOPAZ_SIXTY, 

FS NORMAL, 

FPF ROMFONT 
>; ~ 


struct IntuiText LadenText = 

{ 

4, 1, JAM2, 1,1, SFont, (UBYTE *)"Laden", NULL 
>; 

struct IntuiText SpeichernText = 

< 

4, 1, JAM2, 1, 1, ÄFont, (UBYTE *)"Speichern", NULL 
); 

struct IntuiText LoeschenText = 

{ 

4, 1, JAM2, 1,1, &Font, (UBYTE *)“Löschen'', NULL 
>; 

struct IntuiText ProgrammendeText = 

( 

4, 1, JAM2, 1, 1, SFont, (UBYTE *)"Prograiiinende", NULL 
>; 


Struktur 3.20: Menü-Texte 


Wir haben jetzt zwar die Texte, benötigen aber noch für jeden 
Menüpunkt eine Struktur. Das ist die Menultem-Struktur, die 
alle wichtigen Daten für jeden Menüpunkt äufbewahrt. 
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struct Menultem 

r 

0x00 

00 

struct Menultem *NextItem; 

0x04 

04 

SHORT LeftEdge 

0x06 

06 

SHORT TopEdge; 

0x08 

08 

SHORT Width; 

OxOA 

10 

SHORT Height; 

OxOC 

12 

USHORT Flags; 

OxOE 

14 

LONG HutualExclude; 

0x12 

18 

APTR ItemFill; 

0x16 

22 

APTR SelectFill; 

OxIA 

26 

BYTE Connand; 

0x1 B 

27 

struct Menultem *SubItem; 

0x1 F 

31 

USHORT NextSelect; 

0x21 

33 



>; 


Strukturbeschreibung 

*NextItem 

Ein Zeiger auf den nächsten Menüpunkt. Wir brauchen ihn, um 
mehr als einen Menüpunkt pro Menü zu verwalten. Alle Menü¬ 
punkte eines Menüs werden durch diese Kette verknüpft 

LeftEdge, TopEdge 

Die Position des Aktivierungsbereiches dieses Menüpunktes, der 
ab jetzt Select-Box genannt werden soll. Die Koordinaten sind 
relativ zu LeftEdge und TopEdge der Menüstruktur! 

Width, Height 

Die Ausdehnung der Select-Box des Menüpunktes. 

Flags 

Wieder ein Flag-Wert, mit dem wir die Eigenschaften des 
Menüpunktes einstellen können. 

Normalerweise vermutet Intuition unter ItemFill und SelectFill 
jeweils einen Pointer auf eine Image-Struktur. Durch Setzen des 
Flags ITEMTEXT stellen Sie eine IntuiText-Struktur ein. 

Auf welche Art der Menüpunkt dargestellt werden soll, der au¬ 
genblicklich mit dem Mauspfeil angewählt wird, kann mit den 
HIGHFLAGS-Flags ausgesucht werden. Setzen Sie HIGHCOMP, 
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wird die Select-Box invertiert. Setzen Sie HIGHBOX, wird um 
die Select-Box ein Kasten gezeichnet. Über HIGHIMAGE kön¬ 
nen Sie einstellen, daß ein neuer Text oder eine neue Grafik 
gezeigt wird. Das letzte Flag, HIGHNONE, weist Intuition an, 
nichts zu tun. 

Genau wie auch bei der Menü-Überschrift können wir bei je¬ 
dem Menüpunkt angeben, ob er angewählt werden soll oder 
nicht. Dazu verwenden wir das Flag ITEMENABLED. Setzen Sie 
ITEMENABLED, wenn der Menüpunkt angewählt werden darf. 

Zu jedem Menüpunkt kann eine Kommando-Taste definiert 
werden. Falls eine existiert, ist das Flag COMMSEQ zu setzen. 

Als weiteren Komfort erlaubt es Intuition, bestimmte Menü¬ 
punkte abzuhaken. Dies kennzeichnet das Flag CHECKIT. Der 
Menüpunkt ist dann nicht mehr für einen Funktionsaufruf ge¬ 
dacht, sondern stellt einen aktiven oder inaktiven Zustand dar. 

Soll ein Menüpunkt, der abgehakt werden kann, auch direkt ab¬ 
gehakt sein, wenn das Menü initialisiert wird, dann müssen Sie 
zusätzlich noch das CHECKED-Flag setzen. Sie können dieses 
dann später auch abfragen. 

Intuition hat in der Variablen Flags zwei weitere Flags für sich 
reserviert. So wird ISDRAWN gesetzt, wenn Untermenüpunkte 
des Menüpunktes ausgegeben sind. Das Flag HIGHITEM wird 
gesetzt, wenn der Menüpunkt mit dem Maus-Cursor aktiviert 
wird. 

MutualExclude 

Über die Bits dieser Variablen können wir einstellen, ob andere 
Menüpunkte bei Auswahl dieses Menüpunktes deaktiviert wer¬ 
den sollen. 

ItemFill 

Dieser Pointer zeigt entweder auf eine Image-Struktur oder auf 
eine IntuiText-Struktur. Sie kennzeichnen dies mit dem Flag 
ITEMTEXT. 
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SelectFill 

Der zweite Pointer enthält auch wieder einen Zeiger auf eine 
der beiden Strukturen. Allerdings wird diese nur dargestellt, 
wenn der Menüpunkt aktiviert wird und auch das Highlighting- 
Flag HIGHIMAGE gesetzt ist. 

Command 

Falls unter Flags eine Kommando-Taste definiert wurde, ist hier 
der ASCII-Code des Zeichens zu finden, das den MenQpunkt 
aktivieren soll. 

*SubItem 

Wie Sie vielleicht schon wissen, ist es möglich, die Menüs noch 
auf einer weiteren Ebene zu verschachteln. Dieser Zeiger zeigt 
auf den ersten Untermenüpunkt dieses Menüpunktes. 

NextSelect 

Eine Variable, die erst nach Auswahl des Menüpunktes von In¬ 
tuition gefüllt sein kann. Dann ist nämlich noch ein weiterer 
Menüpunkt ausgewählt worden, und Sie finden hier seine Num¬ 
mer! 

Beginnen wir nach dieser anstrengenden Strukturanalyse mit der 
Programmierung unserer ersten Menüpunkte. Oben haben Sie 
hoffentlich schon die IntuiText-Strukturen gelesen und auch ab¬ 
getippt. Ich habe vier dazu passende Menultem-Strukturen: 

struct Menuitem Programmende = 

C 

NULL, 

1, 40, 

120 , 10 , 

ITEHTEXT I ITEMENABLED j HIGHCOMP, 

0 , 

(APTR )&ProgrammencieText, 

NULL, 

0 , 

NULL, 

0 

>; 


struct Nenultem Loeschen = 
L 
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&Programmetxie, 

1 , 26 , 

120 , 10 , 

ITEMTEXT j ITEMENABLED j HIGHCOMP, 

0 , 

(APTR)&LoeschenText, 

NULL, 

0 , 

NULL, 

0 


struct Henultem Speichern > 
i 

&Loeschen, 

1, U, 

120 , 10 , 

ITEMTEXT j ITEMENABLED | HIGHCOMP, 

0 , 

(APTR)&SpeichernText, 

NULL, 

0 , 

NULL, 

0 


struct Menuitem Laden = 
i 

&Speiehern, 

Ir 2, 

120 , 10 , 

ITEMTEXT I ITEMENABLED | HIGHCOMP, 

0 , 

<APTR)&LadenText, 

NULL, 

0 , 

NULL, 

0 


Struktur 3.21: Menultem-Strukmren zum 1. Menu 


3.8.2.3 Kleine Extras in der Menügestaltung 

Nun soll es Leute geben, die mit den obigen Strukturen, Defini¬ 
tionen, Texten und Einstellungen zufrieden sind. Wir aber nicht! 
Abgesehen davon, daß noch zwei Menüs ohne Menfipunkte exi¬ 
stieren und das erste Menü auch noch Untermenüs bekommen 
soll, ist dieses Menü viel zu fade entworfen. Es fehlt einmal das 
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Extravagante und das Außergewöhnliche, was ein gutes Pro¬ 
gramm auszeichnet, und es fehlt der Bedienerkomfort! Gehen 
wir Schritt für Schritt, unter Beachtung und vollständiger Aus¬ 
schöpfung aller von Intuition angebotenen Extras, vor. 

Zuerst ist der Bedienungskomfort an der Reihe. Er steht leider 
wirklich fast an letzter Stelle. Versetzen Sie sich in folgende Si¬ 
tuation: Sie sind langjähriger Anwender des Programms und 
kennen seine Möglichkeiten, müssen aber immer noch die Maus 
in die Hand nehmen, die Menüs entlangfahren, nur um eine 
Funktion anzuwählen. Ständig der Wechsel zwischen Tastatur, 
Maus und ... 

Viel leichter wäre es, wenn man die Menü-Funktionen auch von 
der Tastatur aus aufrufen könnte. Das ist auch zugelassen, und 
warum sollen wir es dann nicht nutzen? 

Dafür ist ganz einfach das Flag COMMSEQ im Feld Flags der 
Menultem-Struktur zu setzen und der Parameter Command mit 
dem ASCII-Wert der Taste zu "füttern". Dann wird im Menü auf 
der rechten Seite zusätzlich noch die Amiga-Taste mit unserem 
Zeichen dargestellt. Erweitern Sie deshalb die Select-Box des 
Menüpunktes um mindestens die Breite von vier Zeichen (40 Pi¬ 
xel). Ein Zeichen als Zwischenraum, zwei Zeichen für das 
Amiga-Symbol und ein Zeichen für die Taste. Die Kommando- 
Sequenz wird immer mit der rechten Amiga-Taste aufgerufen. 

Erweitern Sie nun alle Select-Box-Breiten um vierzig Pixel, und 
ergänzen Sie das Flag COMMSEQ in den Flag-Feldern. Verges¬ 
sen Sie nicht, überall einen Buchstaben einzusetzen. Ich würde 
folgende empfehlen: L für Laden, S für Speichern, D für Lö¬ 
schen und E für Programmende. Nun sehen die Menuitem- 
Strukturen so aus: 

struct Henultem Programmende = 

< 

NULL, 

1 , 40 , 

170, 10 

ITENTEXT I ITEMENABLED | HIGHCOMP | COMMSEQ, 

0 , 

(APTRI&ProgramnendeText, 
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NULL, 

0x45, 

NULL, 

0 


struct Menultem Loeschen = 
i 

&Programmende, 

1, 26, 

170, 10, 

ITEHTEXT j ITEMENABLED | HIGHCGHP | COMHSEQ, 

0 , 

(APTR)&LoeschenText, 

NULL, 

0x44, 

NULL, 

0 


struct Menultem Speichern = 
i 

&Loeschen, 

1, 14, 

170, 10, 

ITEMTEXT j ITEMENABLED | HIGHCOMP | COMMSEQ, 

0 . 

(APTR)&SpeichernText, 

NULL, 

0x53, 

NULL, 

0 


struct Menultem Laden = 

C 

&Speiehern, 

1 , 2 , 

170, 10, 

ITEMTEXT I ITEMENABLED | HIGHCOMP | COMMSEQ, 

0 , 

(APTR)&LadenText, 

NULL, 

0x4C, 

NULL, 

0 


Struktur 3.22: Menultem-Strukturen zum 1. Menü, 2. Version 
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Hinweis: Beachten Sie, daß Intuition Groß- und Kleinbuch¬ 

staben unterscheidet. Sie können so jede Taste zwei¬ 
mal benutzen. 

Die magere Ausstattung der Menüpunkte ist nicht zufriedenstel¬ 
lend. Der Benutzer erkennt zwar durch die Invertierung, wel¬ 
chen MenOpunkt er gerade ausgewählt hat, aber wir können 
noch mehr unterbringen. Wir wäre es z.B. mit einem Textwech¬ 
sel bei der Löschen-Funktion. Hier könnte doch so etwas wie 
"Wirklich?" erscheinen, damit der Anwender aufgeschreckt wird. 
Immerhin wird auch das über die Highlighting-Flags wunderbar 
unterstützt. Auf geht’s! 

Dazu brauchen wir zunächst eine neue IntuiText-Struktur. Am 
besten verändern wir damit gleichzeitig die Farbe: 

struct IntuiText LoeschenText = 

C 

5, 1, JAM2, 1,1, ÄFont, (UBYTE *)**Löschen ”, NULL 
>; 

struct IntuiText LoeschenTextII = 
i 

5, 1, JAM2, 1, 1, &Font, (UBYTE ♦)”WIRKLICH?”, NULL 
>; 


Struktur 3.23: IntuiTextezu '^Löschen** 

Sie können natürlich auch die Position oder den Zeichensatz än¬ 
dern. Hier sind stehen Ihnen alle Möglichkeiten offen. Probieren 
Sie ruhig einige Varianten aus! 

Vorher dürfen wir aber nicht vergessen, die Menultem-Struktur 
dahingehend zu verändern. Zum einen muß das Flag HIGH- 
COMP durch HIGHIMAGE ersetzt werden, und danach muß 
noch der Pointer SelectFill mit dem Zeiger auf unseren Text 
versehen werden: 

Struct Menultem Loeschen • 
i 

&Prog rammende, 

1. 26, 

170, 10, 

ITEMTEXT I ITEHENABLED | HIGHIHAGE | COMMSEO, 
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0 . 

(APTR)&LoeschenText, 

(APTR)&LoeschenT ext11, 

0x44, 

NULL, 

0 

>; 

Struktur 3.24: Menultem-Struktur "Löschen**; verbessert 

Ich habe die Kommando-Sequenz beibehalten, weil das immer 
am praktischsten ist! Testen Sie doch jetzt mal die Menüauswahl! 
Zur grafischen Gestaltung Ihrer Menüs möchte ich Ihnen raten, 
auch auf die anderen beiden Highlighting-Modi zurückzugrei¬ 
fen. Warum sollte Ihr Menü nicht alle Punkte mit einem Kasten 
umrahmen? Auch das Flag HIGHNONE läßt sich verwenden. 
Gibt es z.B. in einem Menü viele Funktionen, so wäre es gut, 
wenn diese auch noch gegliedert wären. Ich habe dazu einfach 
die Select-Box der Programmende-Funktion etwas tiefer gerückt. 
So entsteht schon eine thematische Trennung. Reicht Ihnen das 
aber nicht, so können Sie einfach einen Grafik- oder Text- 
Menüpunkt mit einem Strich verwenden und diesen nicht abfra¬ 
gen. Für den Benutzer darf dieser Punkt natürlich nicht anwähl¬ 
bar sein, und deshalb setzen Sie das HIGHNONE-Flag! Vermei¬ 
den Sie außerdem von Anfang an eine Fehlbedienung! Denn es 
ist unsinnig, daß die Speicher-Funktion schon aktiv, d.h. an¬ 
wählbar ist, wenn noch nichts zum Abspeichern geschaffen 
wurde. Daraufhin sollten Sie alle Menüs und Menüpunkte über¬ 
prüfen, damit ersparen Sie Programm und Benutzer viel Arbeit, 
die durch Requester entsteht (ITEMENABLE-Flag weglassen). 

struct Menuitem Speichern = 

C 

&Loeschen, 

1 , 14 , 

170, 10, 

ITEMTEXT I HIGHCOMP j COMMSEQ, 

0 , 

(APTR)&SpeichernText, 

NULL, 

0x53, 

NULL, 

0 

>; 


Struktur 3.25: Menultem-Struktur **Speichem**; verbessert 
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3.8.2.4 Komplexere Verschachtelungen: Untermenüs 

Die Gestaltung ist noch nicht ausgereizt, aber unser Weg soll uns 
tiefer in die Menü-Leiste führen. Dort treffen wir auf die Un¬ 
termenüs! Diese Menüs erscheinen, wenn wir in einem Menü 
einen Menüpunkt ausgewählt haben. Es ist durchaus möglich, 
daß dieser nur ein Oberbegriff war und noch eine weitere Aus¬ 
wahl erforderlich ist. 

Wie kommen wir nun zu unserem Untermenü? Dafür sieht man 
sich am besten noch einmal die Menultem-Struktur an. In ihr 
finden wir einen Pointer auf einen Subitem, und genau das ist 
der Eingang zum Untermenü. Fügt man hier den Zeiger auf eine 
neue Menultem-Kette ein, ist das der Anfang zum neuen Un¬ 
termenü. 

Mit dieser Methode ließe sich z.B. das Datei-Menü ergänzen. Ist 
das Datei-Menü für eine Textverarbeitung gedacht, dann muß 
zuvor angegeben werden, welchen Text-Typ das Programm la¬ 
den soll, und dafür benutzen wir das Untermenü. Es stehen drei 
Typen zur Auswahl: Text (das Textformat der Textverarbeitung), 
ASCII (Austauschformat zwischen allen Computern) und IFF 
(genormtes Format vom Electronic Arts). 

struct IntuiText TextText = 

3, 1, JAM2, 1, 1, SFont, (UBYTE •)"Text", MULL 
>; 

struct IntuiText ASCIIText = 

3, 1, JAH2, 1, 1, &Font, (UBYTE *)"ASCII", NULL 
>; 

struct IntuiText IFFText = 

3, 1, JAM2, 1, 1, SFont, (UBYTE *)"IFF", MULL 
>; 

struct Menultem IFF = 

{ 

NULL, 

140, 22, 

100 , 10 , 
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ITEMTEXT j ITEMENABLED | HIGHCOMP | COMMSEQ, 

0 , 

(APTR)&IFFText, 

NULL, 

0x49, 

NULL, 

0 

>; 

struct Menuitem ASCII = 
i 

&IFF, 

140. 12, 

100 , 10 , 

ITEHTEXT I ITEMENABLED | HIGHCOMP j COMMSEO, 

0 , 

(APTR)&ASCIIText, 

NULL, 

0x41, 

NULL, 

0 

>; 

Struct Menuitem Text = 

C 

&ASCII, 

140, 2, 

100 , 10 , 

ITEMTEXT I ITEMENABLED | HIGHCOMP | COMMSEO, 

0 . 

(APTR)&TextText, 

NULL, 

0x54, 

NULL, 

0 

>; 

struct Menuitem Laden = 
i 

ÄSpeiehern, 

1 , 2 , 

170, 10, 

ITEMTEXT I ITEMENABLED | HIGHCOMP, 

0 , 

(APTR)&LadenText, 

NULL, 

0 . 

&Text, 

0 

>: 


Struktur 3.26: Untermenü Laden 
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Das gleiche Untermenü muß nun auch noch bei der Speicher- 
Funktion ergänzt werden. 


Sie müssen nur die Menultem-Struktur mit dem Pointer auf die 
Untermenüs ergänzen und gleichzeitg die Kommando-Sequenz 
entfernen: 


struct Menultem Speichern = 
i 

&Loeschen, 

1, 14, 

170, 10, 

ITEMTEXT j HIGHCOMP | COMMSEQ, 

0 , 

(APTR)&SpeichernText, 

NULL, 

0 , 

&SpeicherText, 

0 


Struktur 3.27: Menultem-Struktur ^Speichern** verbessert 


Leider müsssen auch die Subitems neu definiert werden, weil 
die alten Kommando-Sequenzen nicht doppelt verwendet werden 
können: 


struct Menultem Speicherl FF = 

< 

NULL, 

HO, 22, 

100 , 10 , 

ITEMTEXT I ITEMENABLED | HIGHCOMP | COMMSEQ, 

0 , 

(APTR)&IFFText, 

NULL, 

0x46, 

NULL, 

0 

>; 


struct Menultem SpeicherASCII = 


&SpeicherIFF 
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HO, 12. 

100 , 10 , 

ITEMTEXT j ITEMENABLED | HIGHCOMP | CONMSEQ, 

0 , 

(APTR)&ASCIIText, 

NULL, 

0x43, 

NULL, 

0 


struct Henultem SpeicherText = 

C 

&SpeicherASCII, 

HO. 2, 

100 , 10 , 

ITEMTEXT I ITEMENABLED | HIGHCOMP j COMMSEQ, 

0 . 

<APTR)»TextText, 

NULL, 

0x51, 

NULL, 

0 


>; 


Struktur 3,28: Untermenü ^'Speichern** 

Die IntuiText-Strukturen können wir ohne Bedenken ein zweites 
Mal verwenden, da sie immer nur einmal zur Zeit benutzt wird! 

Für den Menüpunkt "Löschen" hatte ich mir vorgestellt, daß wir 
dort die Auswahl zwischen einer Datei auf der Diskette und dem 
Text (Bild) im Speicher in einem Untermenü bringen. Aber ich 
bin sicher, daß Sie das alleine schaffen, ohne daß es abgedruckt 
werden muß. 


3.8.2.5 Eine Anleitung zum Design-Menü 

Sie sind jetzt endlich an der Reihe und sollen ein einfaches 
Menü selbständig programmieren. Die einzige Hilfe von mir 
wird die Beschreibung des Menüs sein. Sie können dann nach 
Herzenslust die Strukturen definieren und verketten. Also ma¬ 
chen Sie sich an die Arbeit! 
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Das Menü soll aus sechs Schrifttypen bestehen. Diese können 
natürlich alle auch über einen Command-Key aufgerufen wer¬ 
den. Folgende Schriftarten gehören zum Standard: "Normal", 
"Kursiv", "Fett", "Invers", "80 Zeichen" und "60 Zeichen". Jeder 
Menüpunkt muß als IntuiText-Struktur mit eigener TextAttr- 
Struktur definiert werden. In der TextAttr-Struktur geben Sie 
dann immer die jeweilige Schriftart an. Somit hat der Benutzer 
später eine leichte Auswahl und kann sich sofort ein Bild vom 
Textaussehen machen. 

Wenn das Menü aktiviert wird, soll der Anwender auch sofort 
erkennen, welche Schrifttypen momentan angewählt sind. Dafür 
bietet sich das Checkmark an. Setzen Sie dazu das CHECKIT- 
Flag im Flags-Wert. Für das Checkmark selbst, den Haken, 
müssen im IntuiText noch Lücken vor den Text gestellt werden. 
Zwei Leerzeichen dürften ausreichen. Dies empfiehlt sich auch, 
falls das MENUTOGGLE-Flag verwendet wird, weil damit zu¬ 
erst eine Schriftart eingeschaltet und bei erneutem Anwählen 
wieder ausgeschaltet wird. 

Als nächstes müssen wir uns noch um den MutualExclude küm¬ 
mern. Damit können wir einstellen, daß bestimmte Menüpunkte, 
die auch abgehakt werden können, nicht mehr abgehakt sind, 
wenn ein bestimmter anderer abgehakt wurde. Das hört sich 
vielleicht etwas kompliziert an, ist aber sehr einfach und nütz¬ 
lich. Nehmen wir ein konkretes Beispiel: Wenn der Benutzer die 
Schriftart "Normal" anwählt, beabsichtigt er, daß alle anderen 
Schrifttypen wieder deaktiviert werden. Wir erreichen das durch 
MutualExclude. Gleiches gilt auch für die beiden Schriftbreiten. 
Nur eine kann benutzt werden, die andere muß jeweils ausge¬ 
schlossen werden. 

Die MutualExclude-Methode arbeitet folgendermaßen: Wir ha¬ 
ben einen LONG-Wert zur Verfügung, von dem jedes Bit einen 
Menüpunkt repräsentiert. Alle Menüpunkte, die wieder ausge¬ 
schaltet werden sollen, wenn unser bestimmter Menüpunkt an¬ 
gewählt wird, sind dann mit einem gesetzten Bit zu markieren. 
Dabei entspricht das Bit 0 dem ersten Menüpunkt, das Bit 1 dem 
zweiten Menüpunkt usw. 
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3.8.2.6 Grafik-Menü mit Grafiken 

Nachdem im Design-Menü die Schriftart gewählt werden kann, 
werden Sie im "Grafik"-Menü die Auswahl mehrerer Grafiken 
haben und gleichzeitig eine Farbauswahl. Dieses Menü würde 
gut in ein Grafikprogramm passen. 

Das Menü setzt sich aus zwei Menüpunkten zusammen. Der er¬ 
ste, Pinsel, hat ein Untermenü mit zwei weiteren Punkten: einen 
Pinsel mit feiner Spitze und einen mit dicker. (Für Ergänzungen 
bin ich Ihnen jederzeit dankbar.) Der zweite Menüpunkt, Pa¬ 
lette, weist 8 Untermenüpunkte auf, die zum Einstellen der 
Zeichenfarbe dienen. Er ist sowohl für ein Grafikprogramm als 
auch für eine Textverarbeitung zu gebrauchen. 

Hier die Menultem-Strukturen für das Pinsel-Menü: 

struct Menultem Pinseln - 

NULL, 

90, 2, 

10 , 10 , 

ITEMENABLED | HIGHCONP, 

0 , 

<APTR)&PinseUI Image, 

NULL, 

0 , 

NULL, 

0 

>; 


Struct Menultem PinselI = 
< 

ftPinselll, 

102 , 2 , 

10 , 10 , 

ITEMENABLED j HIGHCOMP, 

0 , 

(APTR)&PinselIImage, 
NULL, 

0 , 

NULL, 

0 


Struktur 3.29: Untermenü "Pinsel 
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Und die Menultem-Struktur für das Hauptmenü: 

struct IntuiText PinselText = 

C 

0, 1, JAM2, 1,1, ÄFont, (UBYTE ♦)”Pinsel*', NULL 

>; 

struct Henultem Pinsel = 
i 

&Farben, 

2 . 2 , 

100 , 10 , 

ITEMTEXT I ITEMENABLED j HIGHCOMP, 

0 . 

(APTR)&PinselText, 

NULL, 

0 . 

ftPinsell, 

0 


Struktur 3.30: Menuitem *'Pinser 


Fast hätte ich die beiden Image-Strukturen mit den Werten ver¬ 
gessen: 

USHORT PinsellDatenn = 
i 

0x00, 0x00, 

0x01, OxFO, 

0x00, 0x00, 

0x00, 0x00, 

>; 

USHORT PinselIIDatenC] = 

{. 

0x00, 0x00, 

0x01, OxFO, 

0x01, OxFO, 

0x00, 0x00, 

>; 

struct Image PinselIImage » 
i 

1 . 1 . 

8 , 8 , 

1 , 

&PinselIDaten[0], 

2 , 0 , 

NULL 
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>; 


struct Image Pinsellllmage = 
{ 

1 . 1 . 

8 . 8 . 

2 . 

&PinselIIDaten[0 ], 

2 . 0 , 

NULL 

>; 


Struktur 3.31: Daten/Struktur Pinsel-Image 

Nun folgen die Daten zum Farbauswahl-Untermenü. Wir defi¬ 
nieren dazu eine ganz normale Menultem-Struktur für den 
Menüpunkt. Im Untermenü wird jede Farbe durch eine Intui- 
Text-Struktur vertreten. Aber nun erst zum Hauptmenü: 

Struct IntuiText Farben!ext = 
i 

0, 1, JAM2, 1,1, ÄFont, (UBYTE ’^)**Farben», NULL 
>; 


struct Menuitem Farben = 


C 

NULL, 

2, 14, 

100 , 10 , 

ITEMTEXT I ITEMENABLED 

0 , 

(APTR)&FarbenText, 

NULL, 

0 , 

&Farbe0, 

0 


>; 


HIGHCOMP, 


Struktur 3.32: Menuitem "Farben" 


Für die Farben nehmen wir wie oben eine IntuiText-Struktur, 
die nur Leerzeichen enthält. Dafür wird die Hintergrundfarbe 
gewechselt, so daß Farbbalken entstehen. Ich zeige hier nur die 
ersten drei, alle anderen sind leicht zu konstruieren: 

struct IntuiText ColOText = 
t 

0, 0, JAM2, 1, 1, 4Font, (UBYTE *)•' ", NULL 
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>; 

struct IntuiText CoUText = 
i 

0, 1, JAM2, 1,1, &Font, (UBYTE *)” ", NULL 

>; 

struct IntuiText ColZText = 

< 

0, 2, JAM2, 1,1, ÄFont, (UBYTE *)" ", NULL 

>; 


Struktur 3,33: IntuiTexte Menü ''Farben” 

Nach dem gleichen Prinzip erfolgt die Definition der Menuitem- 
Strukturen für das Untermenü: 


Struct Menuitem Farbe2 = 
i 

&Farbe3, 

90, 26, 

50, 10, 

ITEMTEXT j ITEMENABLEO j NIGHBOX, 

0 . 

(APTR)&Col2Text, 

NULL, 

0 , 

NULL, 

0 

>; 

Struct Menuitem Farbel = 

< 

&Farbe2, 

90, 14, 

50, 10, 

ITEMTEXT j ITEMENABLEO j HIGHBOX, 

0 , 

(APTR)&Col1Text, 

NULL, 

0 , 

NULL, 

0 

>; 

struct Menuitem FarbeO > 
i 


&Farbe1 
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90. 2. 

50, 10, 

ITEMTEXT I ITEMENABLED | HIGHBOX, 

0 . 

<APTR)&ColOText, 

NULL, 

0 . 

NULL, 

0 


Struktur 3.34: Menultem-Strukturen Menü ^Farben” 


3.8.3 Die Abfrage der gesamten Menüleiste 

Die Menüleiste dieses Kapitels stellt einen Universaltyp dar, da 
sie aus mehr als einem Menü, einem Menüpunkt und mehr als 
einem Untermenüpunkt besteht. Außerdem finden wir Menü¬ 
punkte, die Aktionen auslösen, genauso wie solche, die für eine 
bestimmte Eigenschaft stehen. Aus diesem Grund eignet sich die 
Menü-Leiste besonders für eine allgemeine Abfrage. Sie können 
die Unterroutine in jedem eigenen Programm verwenden, weil 
die Menü-Abfrage besonders flexibel ist. 

Wie für jede Abfrage des IDCMP, müssen zuerst die richtigen 
Vorausssetzungen geschaffen werden. Hierfür setzen Sie bitte das 
MENUPICK-Flag in der Variable IDCMP des Windows. 

Als nächstes testen wir in der bekannten Abfrageschleife auf 
eine Menünachricht: 

FOREVER 

if ((message = (struct IntuiHessage *) 

GetMsg(FirstUinck>w*>UserPort)) == NULL) 

C 

Uait(1L « FirstWindow->UserPort->mp_SigBit); 
continue; 

> 

MessageClass - message->Class; 

Code s message->Code; 

ReplyHsg(message); 
switch (HessageClass) 

C 
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case CLOSEWINDOU : Close.AUO; 

exit(TRUE); 

break; 


case MENUPICK 


> 


> 


> 


Henu_Auswertung(Code); 
break; 


Progframmteü 3.11: Abfrageschleife Menütest 

Haben wir eine Nachricht vom Typ MENUPICK erhalten, so 
wird in die Funktion Menu_Auswertung verzweigt, wo wir 
einen Punkt nach dem anderen prüfen können. 

Menu^Auswe r t ung(Menunummern) 

USHORT Menunummer; 
i 

USHORT Menu, Menuitem, Subltemm, NextMenu; 
struct Menuitem ^MenuPunkt; 

Menu s MENUNUM(Menunummern); 

Menuitem » ITEMNUMCMenunummern); 

Subitem » SUBITEM(Menunummern); 

MenuPunkt = ItemAckJressC&Oatei, Menunummern); 

switch(Menu) 

i 

case 0 : /* Datei - Menü */ 
break; 

case 1 : /* Design - Menü V 
break; 

case 2 : /* Grafik - Menü */ 
break; 

> 

NextMenu » MenuPunkt->NextSelect; 
if (NextMenu) Menu_Au8wertung(NextMenu); 


> 


Funktion 3.11: Menü-Auswertung 
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Hier haben wir zuerst die Unterscheidung nach den jeweiligen 
Menüs. Außerdem berechnet das Programm anhand der Funktion 
ItemAddressO die Adresse der Menultem-Struktur. Somit können 
wir weitere Daten auslesen. Dies wird auch am Ende der neuen 
Funktion genutzt, wenn nämlich der Wert NextSelect auf eine 
neue Menünummer überprüft wird. Somit unterstützt diese Rou¬ 
tine auch das Auswählen von mehreren Menüpunkten! 

Gehen wir die Abfragen der Reihe nach durch, zuerst das Da¬ 
tei-Menü. Wir unterscheiden vier Menüpunkte: 

switch(Menultein) 

case 0 : /* Laden */ 
break; 

case 1 : /* Speichern */ 
break; 

case 2 : /* Löschen V 
DeleteO; 
break; 

case 3 : /* Programmende */ 

Ende FALSE; 
break; 

> 


Programmteü 3.12: Austesten der Menüs 

Die letzten beiden Punkte lassen es zu, sofort eine Aktion aus¬ 
zulösen. Nur bei den ersten muß weiter geprüft werden: 

case 0 : /* Laden */ 

switch(Sublteni) 

{ 

case 0 : /* Text */ 

Load(TEXT); 

break; 

case 1 ; /* ASCII */ 

Load(ASCII); 

break; 

case 2 : /* IFF V 
Load(IFF); 
break; 
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> 

break; 

case 1 : /* Speichern */ 

switch(Subitem) 

< 

case 0 : /* Text */ 

Save(TEXT); 

break; 

case 1 : /* ASCII V 
Save(ASCII); 
break; 

case 2 : /* IFF V 
Save(IFF); 
break; 

> 

break; 

Programmteil 3.13: Austesten der Untermenüs **Laden*' und ''Speichern** 

Alle Überprüfungen eines Untermenüs rufen die gleiche Funk¬ 
tion auf. Allerdings werden dieser jedesmal andere Parameter 
übergeben. In diesem Fall sind es selbst definierte Flags. So sagt 
TEXT dem Unterprogramm Load() oder Save(), daß es die eige¬ 
nen Kommandosequenzen erwarten oder schreiben soll. ASCII 
unterbindet jede Formatangabe, und IFF schreibt die allgemein 
definierten Formatangaben vor. 

Beim zweiten Menü müssen wir einen anderen Weg der Abfrage 
beschreiten. Wir haben hier keine Untermenüs, sondern nur ein 
Hauptmenü, in dem mehrere Eigenschaften stehen, von denen 
fast alle miteinander kombinierbar sind. Nur die Schriftbreiten 
vertragen sich nicht. Nimmt man an, daß das Programm eine 
Variable für den Schrifttyp und eine für die Zeichenbreite ver¬ 
waltet, so könnte die folgende Abfrage sinnvoll sein: 

suitch(Menultein) 

t 

case 0 : /* Normal */ 

Textstyle » NULL; 
break; 

case 1 : /* Kursiv •/ 

Textstyle KURSIV; 
break; 
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case 2 : /* Fett V 
Textstyle *= FETT; 
break; 

case 3 : /* Invers V 
Textstyle “= INVERS; 
break; 

case 4 : /* 80 Zeichen V 
TextFont = 801; 
break; 

case 5 : 60 Zeichen V 

TextFont = 60L; 
break; 

> 


Programmteil 3.14: Austesten des Menüs ^'Design” 

Im dritten Menü kann wieder die einfache Abfrage benutzt 
werden. Wir unterscheiden hier zwei Klassen. Die erste beschäf¬ 
tigt sich mit den "Pinseln". Man findet in der Variablen PinselNr 
später dann die Nummer des ausgewählten Pinsels vor. Das 
gleiche in der Farbauswahl: In der Variablen FarbNr steht nach 
der Menüauswahl für das Programm die Farbnummer. 


switch(MenuItem) 
i 

case 0 : /* Pinsel V 
PinselNr = Subitem + 1; 
break; 

case 1 : /* Farbe V 
FarbNr = Subitem; 
break; 

> 


Programmteil 3.15: Austesten Uruermenüs Xlrafik” 


3.8.4 Die Arbeit mit Source-Code-Utiiitiee 

Was versteht man eigentlich unter einem Source-Code-Utility? 

Wir bezeichnen damit Programme, die dem Programmierer bei 
seiner Arbeit am Programmtext helfen. Das sind meist Pro- 
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gramme, die aufwendige Arbeiten erledigen, die sehr schwer 
theoretisch zu bearbeiten sind, weil viel von der Grafik abhängt. 
Sie erfordern aber keine schwierigen Dateneingaben, sondern 
arten mehr in Schreibarbeit aus. Diese Schreibarbeit nimmt ei¬ 
nem das Source-Code-Utility ab. Es besorgt alle Definitionen, 
die eindeutig sind, und erlaubt es dem Entwickler, diese nach¬ 
träglich zu verändern. 

Gerade bei der Programmierung von Intuition erweisen sich 
solche Utilities als sehr hilfreich. Sie werden gemerkt haben, daß 
bereits für ein neues Window einige Parameter notwendig waren. 
Noch komplexer wurde es bei den Gadgets, die immer mit einer, 
zwei oder drei Strukturen erweitert wurden. Bei den Requestern 
merkte man, was für Fingerarbeit geleistet werden mußte. 

Nun sind wir aber an einem Punkt angelangt, an dem es nicht 
mehr tragbar ist, alle Strukturen selber zu schreiben. Da Menüs 
nur in ein Programm eingebaut werden, wenn es viele Funktio¬ 
nen gibt, die darüber angeboten werden können, ergibt es sich 
von selbst, daß wir pro Menüpunkt mindestens zwei Strukturen 
brauchen. Es ist nicht seiten, daß ein Programm über SO Menü¬ 
punkte verwaltet. BECKERtext von DATA BECKER hat z.B. 
derzeit S Menüs mit insgesamt 63 Menüpunkten und 63 Unter¬ 
menüpunkten. Sie müßten dafür 126 Menultem-Strukturen und 
genausoviele IntuiText-Strukturen definieren, hätten dann aber 
nur die rohen Menüs. Diese Arbeit kann uns ein Programm ab¬ 
nehmen. 


3.8.4.1 Die Bedienung von PowerWindows 

PowerWindows ist ein Programm, das verspricht, dem Program¬ 
mierer die Arbeit abzunehmen. Es ist aber nicht nur für die 
Programmierung von Menü-Strips vorgesehen. Es unterstützt 
ebenfalls die Handhabung von Windows und Gadgets. Es werden 
demnach die drei wichtigsten Grundelemente Intuitions verar¬ 
beitet. Aus den Gadgets kann der Programmierer dann z.B. 
selbst Requester bauen. 
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Kommen wir nun zu der Bedienung dieses Programms. Nach 
dem Laden erscheint ein großes Window, zu dem wir nur die 
Menüleiste finden. Hier können wir nur wählen zwischen dem 
Laden eines alten Windows, dem Erstellen eines neuen Windows 
oder dem Verlassen des Programms. Natürlich wählt man ein 
neues Window. 

Das Window erscheint sofort und eine neue Menüleiste tut sich 
dem Entwickler auf: Wir haben jetzt fünf Menüs, von denen 
drei die Intuition-Elemente betreffen. Die anderen werden für 
File-Arbeit und allgemeine Einstellungen benutzt. 

In der File-Arbeit ist es möglich, einen Assembler-Code, einen 
C-Code oder einen programminternen Code zu erzeugen. Der 
letzte ist dafür da, ein Projekt noch weiter behandeln zu kön¬ 
nen, da es in den anderen beiden Formen nicht mehr für Po- 
werWindows zu verarbeiten ist. 

Das Preferences-Menü erlaubt einige Einstellungen zum Quell¬ 
text. So kann dieser mit Kommentaren (Standard) versehen wer¬ 
den, und auch der Tabulator im Text ist einstellbar. Weiterhin 
können Sie das Programm beauftragen, darauf zu achten, daß 
sich z.B. keine Gadgets überlappen. 


3.8.4.2 Eine Menüleiste erstellen "lassen" 

Machen wir uns jetzt daran, die ersehnte Menüleiste aufzubauen. 
Dafür sehen wir ins Menü "Menü" und entdecken nur einen 
Menüpunkt, der anwählbar ist. Wir dürfen unserem Window ein 
ganzes Menü anfügen. Das wählen wir aus, und ein Requester 
erscheint. In diesen kann der Name des neuen Menüs eingegeben 
und mit OK bestätigt werden. Diese Bestätigung stört in der 
späteren Arbeit noch unangenehm, denn der Return-Tasten- 
Druck im String-Gadget sollte nach Amiga-Konventionen ei¬ 
gentlich genügen. 

Klickt man jetzt sein kleines Window an und sieht in die 
Menüleiste, findet man wirklich sein erstes Menü. Sogar ein 
Menüpunkt wurde schon eingesetzt, er ist allerdings ausgeschal- 
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tet. Jetzt wird ein weiteres Problem sichtbar, das sich leider 
nicht beheben läßt. Zum Ausführen eines Befehls von Power- 
Windows muß immer wieder das PowerWindow-Fenster an¬ 
geklickt werden und zum Betrachten der Menüleiste das eigene 
Fenster. 

Geplant ist, die Menüleiste, die wir zu Anfang dieses Kapitels 
zusammen programmiert haben, auch mit PowerWindows zu er¬ 
stellen. Damit haben wir einen guten Vergleich. Ich schaffe des¬ 
halb erst einmal drei Menüs mit den Titeln "Datei", "Design" und 
"Grafik". 

Dafür stehen noch mehr Funktionen als nur "Append a menu" 
zur Verfügung. Hier soll aber keine Programmbeschreibung ab¬ 
gedruckt werden, sondern nur eine kurze Kommentierung der 
Arbeitsschritte. 

Sind die drei Menüs fertig, kommen wir zu den Menüpunkten. 
Wählen Sie dafür die Funktion "Work on Menuitems for ..." an. 
In einem Untermenü können Sie das Menü bestimmen, dessen 
Menüpunkte Sie editieren wollen. Nehmen wir zuerst "Datei". 

Eine andere Menüleiste hat sich uns zur Verfügung gestellt. Sie 
dient ausschließlich der Bearbeitung der Menuitems. Fügen wir 
einen nach dem anderen an: "Laden", "Speichern", "Löschen" und 
"Programmende". Sehen Sie sich einmal das Menü an. Es fällt 
auf, daß die Positionierung automatisch gemacht wird und leider 
auch nicht beeinflußt werden kann. 

Kommen wir jetzt zu den Untermenüs. Zuerst das "Laden"- 
Menü. Gehen Sie über das Menü in "Work on subitems for ..." 
und stellen Sie "Laden" ein, wieder erscheint eine neue Menülei¬ 
ste, die aber der vorangegangenen sehr ähnlich ist. Hier fügen 
Sie bitte die Punkte "Text", "ASCII" und "IFP ein. Machen Sie 
danach das gleiche für das "Speichern"-Menü. 

Beim Betrachten des bisher erstellten Menüs fällt etwas auf. Wir 
können die Position des Untermenüs nicht bestimmen! Außer¬ 
dem wird das Untermenü nicht gerade großzügig verwaltet. Alle 
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diese Mängel können nachher am Quelltext behoben werden, 
doch eigentlich wollte man sich Arbeit sparen. 

Wählen Sie jetzt den Menüpunkt "Options for" im Subitem- oder 
Item-Menü an. Dort können Sie alle Flags und Ergänzungen 
einstellen. Die Handhabung eines Kommando-Keys wird so 
einfach, und die Farbeinstellungen sind auch vorbildlich gelöst. 

Das erste Menü ist somit abgeschlossen. Sie können natürlich 
noch Kommando-Sequenzen und anderes einfügen, wir gehen 
aber vorher schon an das zweite Menü. Dort sind sechs Menü¬ 
punkte einzurichten, die Ihnen ja bekannt sind. Denken Sie 
daran, für jeden eine Taste und ein Checkmark vorzusehen. Al¬ 
lerdings bekommen wir Probleme, wenn wir außerdem Kursiv¬ 
schrift oder die anderen Typen darstellen wollen. Hier muß die 
Änderung zu einem späteren Zeitpunkt durchgeführt werden. 
Auch MutualExclude wird nicht vom Programm eingestellt. 

Im letzten Menü gibt es Probleme mit den Grafiken. Diese wer¬ 
den von PowerWindows nicht unterstüzt. Allerdings kann man 
sich dabei mit Texten helfen, die später ersetzt werden. Es ist 
verständlich, denn eine Grafikverwaltung würde erheblich mehr 
Aufwand bedeuten. Die Farbauswahl dürfte eigentlich keine 
Schwierigkeiten machen. 

Damit ist die Arbeit abgeschlossen. In dieser Beschreibung fin¬ 
den Sie zwar nicht alle Schritte, aber die Möglichkeiten sind Ih¬ 
nen vertraut. Sie werden im folgenden Quelltext auch noch ge¬ 
nau die Einstellungen ablesen können. 


3.8.4.3 Der entstandene Quelltext 

PowerWindows erlaubt das Erzeugen von Quelltexten für 
Assembler- und C-Programme. Uns interessiert natürlich nur 
das letztere. Nach dem Abspeichern im Format von PowerWin¬ 
dows habe ich das oben beschriebene Menü mit Kommentaren 
und einem Tabulator von 3 Zeichen als C-Quelltext schreiben 
lassen. Sehen Sie, was daraus geworden ist; 
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struct IntuiText ITextl = i 

3,7,JAM2, /* front and back text pens and draumode V 

20,1, /* XY origin relative to Container TopLeft V 

NULL, /’*' font pointer or NULL for defaults V 
*• ”, /* pointer to text */ 

NULL /* next IntuiText structure V 


struct Henultem SubltemS = i 

NULL, /* next Subltem structure V 
34,62, /* XY of Item hitbox relative to 
TopLeft of parent hitbox */ 

68,10, /* hit box width and height */ 

CHECKIT't-ITEMTEXT-t'ITEMENABLED-t'HIGHBOX, /* Item flags V 

0, /* each bit mutual ly-excludes a same*level Item V 

(APTR)&IText1, /* Item render (IntuiText or Image or NULL) V 

NULL, /♦ Select render V 

NULL, /* alternate command-key V 

NULL, /* no Subltem list for Subitems V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText2 = < 

3,6,JAM2, /* front and back text pens and draumode V 

20,1, /* XY origin relative to Container TopLeft */ 

NULL, /* font pointer or NULL for defaults V 
” ”, /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menuitem Subltem/ = i 

ÄSubltemB, /* next Subltem structure */ 

34,52, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
68,10, /♦hit box width and height V 
CHECKIT-»-ITEMTEXT+ITEMENABLED-»-HIGHBOX, /♦ Item flags V 

0, /♦ each bit mutually-excludes a same-level Item ♦/ 

(APTR)&IText2, /♦ Item render (IntuiText or Image or NULL) */ 
NULL, /* Select render */ 

NULL, /* alternate command-key V 

NULL, /♦ no Subltem list for Subitems V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText3 = i 

3,5,JAH2, /♦ front and back text pens and draumode ♦/ 

20,1, /♦ XY origin relative to Container TopLeft */ 

NULL, /♦ font pointer or NULL for defaults V 
” ”, /♦ pointer to text V 

NULL /♦ next IntuiText structure ♦/ 


struct Menuitem Subltem6 - i 

&SubItem7, /* next Subltem structure V 
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34,42, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

68,10, /* hit box width and height V 

CHECKIT+ITEMTEXT+ITEMENABLED+HIGHBOX, /* Item flags */ 

0, /* each bit mutually-excludes a same-level Item */ 

(APTR)&IText3, /* Item render (IntuiText or Image or NULL) */ 

NULL, /* Select render V 

NULL, /* alternate command-key V 

NULL, /* no Subitem list for Subitems V 

OxFFFF /* fiUed in by Intuition for drag selections */ 


struct IntuiText IText4 = < 

3,4,JAM2, /* front and back text pens and drawmode V 

20,1, /* XY origin relative to Container TopLeft */ 

NULL, /* font pointer or NULL for defaults V 
" ", /* pointer to text */ 

NULL /* next IntuiText structure */ 


struct Menuitem SubltemS = i 

&SubItem6, /* next Subitem structure V 
34,32, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

68,10, /* hit box width and height */ 

CHECKIT+ITEMTEXT+ITEMENABLED+HIGHBOX, /* Item flags */ 

0, /♦ each bit mutual ly*excludes a same-level Item V 

(APTR)&IText4, /* Item render (IntuiText or Image or NULL) */ 
NULL, /* Select render V 

NULL, /* alternate command-key */ 

NULL, /* no Subitem list for Subitems */ 

OxFFFF /* filled in by Intuition for drag selections */ 


struct IntuiText ITextS = < 

3,3,JAM2, /* front and back text pens and drawmode */ 

20,1, /* XY origin relative to Container TopLeft V 

NULL, /* font pointer or NULL for defaults */ 

" ", /* pointer to text V 

NULL /* next IntuiText structure */ 


struct Menuitem Subltem4 = i 

ÄSubltemS, /* next Subitem structure */ 

34,22, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

68,10, /* hit box width and height */ 

CHECKIT+ITEMTEXT-HTEMENABLED+HIGHBOX, /* Item flags */ 

0, /* each bit mutually-excludes a same-level Item */ 

(APTR)&IText5, /* Item render (IntuiText or Image or NULL) V 

NULL, /* Select render V 

NULL, /* alternate command-key V 

NULL, /* no Subitem list for Subltems V 

OxFFFF /* filled in by Intuition for drag selections V 
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struct IntuiText IText6 = i 

3,2,JAM2, /* front and back text pens and draumode */ 

20,1, /* XY on'gin relative to Container TopLeft */ 

NULL, /* font pointer or NULL for defaults */ 

" ", /* pointer to text */ 

NULL /* next IntuiText structure */ 


struct Menuitem Subltenß = <; 

&SubItefn4, /* next Subitem structure V 
34,12, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
68,10, /* hit box width and height */ 

CHECKIT+ITEMTEXT+ITEMENABLED+HIGHBOX, /* Item flags */ 

0, /* each bit mutual ly-excludes a same-level Item */ 

(APTR)&IText6, /* Item render (IntuiText or Image or NULL) V 

NULL, /* Select render V 

NULL, /* alternate command-key V 

NULL, /* no Subitem list for Subitems V 

OxFFFF /* filled in by Intuition for drag selections */ 


struct IntuiText IText7 = i 

3.1, JAM2, /* front and back text pens and draumode */ 

20.1, /* XY origin relative to Container TopLeft */ 
NULL, /* font pointer or NULL for defaults V 

" ", /* pointer to text V 

NULL /* next IntuiText structure */ 


struct Menuitem Subltein2 = < 

ÄSubltenö, /* next Subitem structure V 
34,2, /♦ XY of Item hitbox relative 

to TopLeft of parent hitbox V 
68,10, /* hit box width and height V 

CHECKIT+ITEMTEXT-t-ITEMENABLED+HIGHBOX, /* Item flags */ 

0, /* each bit mutual ly-excludes a same-level Item */ 

<APTR)&IText7, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 

NULL, /* alternate command-key */ 

NULL, /* no Subitem list for Subitems */ 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText8 = i 

3,0,JAM2, /* front and back text pens and draumode V 

20,1, /* XY origin relative to Container TopLeft */ 

NULL, /* font pointer or NULL for defaults */ 

" ", /* pointer to text V 

NULL /* next IntuiText structure V 
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struct Menultem Sublteml = < 

&SubItefn2, /* next Subitem structure V 
34,-8, XY of Item hitbox relative 

to TopLeft of parent hitbox V 

68,10, /* hit box width and height V 

CHECKIT+ITEMTEXT+ITEMENABLED+HIGHBOX+CHECKED, /* Item flags */ 
0, /* each bit mutually-excludes a same-Level Item V 

(APTR)&IText8, Item render (IntuiText or Image or NULL) V 
NULL, /♦ Select render */ 

NULL, /* alternate command-key */ 

NULL, /* no Subitem list for Subitems V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText9 = < 

3.1, COMPLEMENT, /* front and back text pens and draumode */ 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
“Farbe“, /* pointer to text V 

NULL /* next IntuiText structure V 

>; 


struct MenuItem Menultem2 > C 

NULL, /* next Menuitem structure V 
0,11, /* XY of Item hitbox relative to 

TopLeft of parent hitbox V 

49,10, i* hit box width and height V 
ITEMTEXT^ITEMENABLED-i-HIGHCOMP, /* Item flags V 
0, !* each bit mutually-excludes a same-Level Item */ 

(APTR)&IText9, /♦ Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 

NULL, /* alternate command-key V 

&SubItem1, /* Subitem list V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText ITextIO = < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 

NULL, /* font pointer or NULL for defaults V 
“!!!“, /* pointer to text V 

NULL /♦ next IntuiText structure V 


struct Menuitem SubltemIO = C 

NULL, /* next Subitem structure V 
59,0, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

25,10, /* hit box width and height V 

ITEMTEXT-t-ITEMENABLED-t-HIGHCOMP, /* Item flags */ 

0, /* each bit mutually-excludes a same-Level Item */ 

(APTR)&IText10, /* Item render (IntuiText or Image or NULL) */ 
NULL, /* Select render */ 

NULL, /* alternate command-key */ 
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NULL, /* no Subltem list for Subltenis V 

OxFFFF /* fiUed in by Intuition for drag selections */ 


struct IntuiText ITextll = < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 

NULL, /* font pointer or NULL for defaults V 
*•???*•, /* pointer to text */ 

NULL /* next IntuiText structure V 

>; 


struct Henultem SubltemP = < 

&SubItem10, /* next Subltem structure */ 

34,0, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
25,10, /* hit box width and height V 

ITEMTEXT-t-ITEHENABLED-i-HIGHCOHP, /* Item flags V 
0, /* each bit mutually-excludes a same*level Item V 

(APTR)&IText11, /* Item render (IntuiText or Image or NULL) */ 

NULL, /* Select render V 

NULL, I* alternate command-key V 

NULL, /* no Subltem list for Subitems V 
OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText12 = f 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /♦ font pointer or NULL for defaults V 
"Pinsel", i* pointer to text V 

NULL /* next IntuiText structure V 

>; 


struct Menuitem Menulteml = 

&HenuItem2, I* next Menuitem structure V 
0,0, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
49,10, /* hit box width and height V 

ITEMTEXT+ITEMENABLED+HIGHCOMP, /* Item flags V 
0, /* each bit mutual ly*excludes a same*level Item V 

(APTR)&IText12, /♦ Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 

NULL, /♦ alternate command-key V 

&SubItem9, !* Subltem list V 

OxFFFF /* filled in by Intuition for drag selections V 


struct Menu Menu3 = i. 

NULL, /* next Menu structure */ 

135,0, /* XY origin of Menu hit box 

relative to screen TopLeft */ 
66,0, /* Menu hit box width and height V 

MENUENABLED, /* Menu flags V 
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"Grafik”, text of Menu name V 
&MenuItem1 /* Menuitem linked list pointer V 


struct IntuiText IText13 = C 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

20.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 

”60 Zeichen”, /* pointer to text V 
NULL /* next IntuiText structure V 


struct Menuitem MenuItemB - C 

NULL, /* next Menuitem structure V 
0,55, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
140,10, !* hit box width and height V 

CHECKIT-HTEMTEXT+COMMSEQ+ITEMENABLED+HIGHCOMP, /* Item flags V 
0, /* each bit mutual ly-excludes a same-level Item */ 

(APTR)&IText13, /♦ Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 
”6”, /* alternate command-key */ 

NULL, /* Subitem list */ 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText14 = < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

20.1, /♦ XY origin relative to Container TopLeft V 
NULL, /♦ font pointer or NULL for defaults V 

”80 Zeichen”, /* pointer to text V 
NULL /* next IntuiText structure V 


struct Menuitem MenuItemZ = C 

ÄMenuItemB, /* next Menuitem structure V 
0,44, !* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
140,10, /* hit box width and height V 

CHECK IT-»-1 TEMTEXT'i-COMMSEQ-i' I TEMENABLED-^H I GHCOMP-f-CHECKED, 

/♦ Item flags V 

0, /* each bit mutual ly-excludes a same-level Item V 

(APTR)&IText14, /* Item render (IntuiText or Image or NULL) V 

NULL, /* Select render V 

”8”, /♦ alternate command-key V 

NULL, /* Subitem list V 

OxFFFF /♦ filled in by Intuition for drag selections V 

>; 


struct IntuiText IText15 = < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

20.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Invers”, /* pointer to text V 
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NULL /* next IntuiText structure V 

>; 


struct Henultem Menultem6 = i 

&Henulteni7, /* next Menuitem structure */ 

0,33, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

140,10, /* hit box width and height */ 

CHECK I T-i-1 TEMTEXT-i'COHHSEQ’t'MENUTOGGLE’i' ITEHENABLED+HIGHCOMP, 

/* Item flags V 

0, /* each bit mutually’excludes a same-Level Item V 

(APTR)&IText15, /* Item render (IntuiText or Image or NULL) V 

NULL, /* Select render V 

**V", /* alternate command-key V 

NULL, /* Subitem list */ 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText16 = i 

3.1, COMPLEMENT, /* front and back text pens and drawmode V 

20.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Fett", /* pointer to text V 

NULL /* next IntuiText structure */ 

>; 

struct Menuitem MenuItemS = < 

&MenuItem6, /* next Menuitem structure V 
0,22, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

140,10, /* hit box width and height */ 

CHECK I T-f I TEMTEXT-i'COMMSEQ’i'MENUTOGGLE-t' I TEMENABLED-t-H I GHCOMP, 

/* Item flags V 

0, /* each bit mutually*excludes a same*Level Item */ 

(APTR)&IText16, /* Item render (IntuiText or Image or NULL) */ 
NULL, /* Select render */ 

”T**, /* alternate command-key V 

NULL, /* Subitem list V 

OxFFFF /* filled in by Intuition for drag selections V 

>; 


struct IntuiText ITextIZ = < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

20.1, /♦ XY origin relative to Container TopLeft V 
NULL, /♦ font pointer or NULL for defaults V 
“Kursiv”, /* pointer to text V 

NULL /* next IntuiText structure V 

>; 


struct Menuitem Menultem4 = i 

ÄMenuItemS, /* next Menuitem structure */ 
0,11, /* XY of Item hitbox relative 

to TopLeft of parent hitbox */ 

140,10, /* hit box width and height V 
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CHECK IT-*-1 TEMTEXT-t-COHMSEQ-i-MENUTOGGLE-i-1 TEHENABLED*i>H IGHCOMP, 

/* Item flags */ 

0, /* each bit mutually-excludes a same*Level Item */ 

(APTR)&IText17, /* Item render (IntulText or Image or NULL) */ 

NULL, /* Select render V 

*‘K", /* alternate command-key V 

NULL, /* Subitem List V 

OxFFFF i* fl Lied in by Intuition for drag selections V 


struct IntuiText IText18 = < 

3.1, C0MPLEMENT, /* front and back text pens and draumode V 

20.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Normal**, /* pointer to text V 

NULL /♦ next IntuiText structure V 

>; 


struct Menuitem Henultenß = < 

&HenuItefn4, /* next Menuitem structure V 
0,0, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
140,10, /* hit box width and height V 

CHECK IT+1TEMTEXT+COMMSEQ+MENUTOGGLE+1 TEMENABLED-»-H IGHCOMP+CHECKED, 
/* Item flags V 

0, /* each bit mutual ly*excludes a same-Level Item V 

(APTR)&IText18, /* Item render (IntuiText or Image or NULL) */ 

NULL, /* Select render V 

**N**, /♦ alternate command'key V 

NULL, /* Subitem list V 

OxFFFF /* filled in by Intuition for drag selections V 


struct Menu Menu2 = C 

&Menu3, /* next Menu structure V 
63,0, /* XY origin of Menu hit box 

relative to screen TopLeft V 
66,0, /* Menu hit box width and height V 

MENUENABLED, /* Menu flags V 
**Design**, /* text of Menu name V 
&MenuItefiß /* Menuitem linked list pointer V 


struct IntuiText IText19 = < 

3.1, C0MPLEMENT, /* front and back text pens and draumode V 

1.1, /* XY origin relative to Container TopLeft */ 

NULL, /* font pointer or NULL for defaults V 
**Programmende**, /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menuitem Menultem12 « i. 

NULL, /* next Menuitem structure V 
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0,33, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

137,10, /* hit box width and height */ 

ITEMTEXT^COMHSEQ-i'ITEMENABLED-^HIGHCOMP, /* Item flags V 
0, /* each bit mutually-excludes a same-Level Item */ 

(APTR)&IText19, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 
"E”, /* alternate command-key */ 

NULL, /* Subitem list V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText20 = C 

3.1, C0HPLEHENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Löschen”, /♦ pointer to text V 

NULL /* next IntuiText structure */ 

>; 


struct Henultem Menultemll = i 

&HenuItem12, /* next Menuitem structure V 
0,22, /♦ XY of Item hitbox relative 

to TopLeft of parent hitbox V 

137,10, /* hit box width and height V 

ITEMTEXT+COMMSEQ+ITEMENABLED+HIGHCOMP, /* Item flags V 
0, /* each bit mutually-excludes a same-Level Item */ 

(APTR)&IText20, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 
"0", /* alternate command-key V 

NULL, /* Subitem list V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText21 = C 

3.1, C0MPLEMENT, /* front and back text pens and drawmode */ 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"IFF”, /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menuitem Subltem13 = < 

NULL, /* next Subitem structure */ 

122,12, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

81,10, /* hit box width and height V 

ITEMTEXTi-COMMSEOi-ITEMENABLED-i-HIGHCOMP, /* Item flags */ 

0, /* each bit mutually-excludes a same-Level Item */ 

(APTR)&IText21, /* Item render (IntuiText or Image or NULL) V 

NULL, /* Select render V 

"F”, /* alternate command-key V 

NULL, /* no Subitem list for Subltems V 

OxFFFF /* filled in by Intuition for drag selections V 
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struct IntuiText IText22 = i 

3.1, C0HPLEMENT, /* front and back text pens and draumode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults */ 

“ASCII", /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menuitem Subltem12 > i 

&SubItem13, /* next Subitem structure V 
122,2, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
81,10, /* hit box width and height */ 

ITEMTEXT-i-COMMSEQ+ITEMENABLED+HIGHCOMP, /* Item flags V 
0, /* each bit mutual ly-excludes a same-level Item */ 

(APTR)&IText22, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render */ 

"C", /* alternate command-key */ 

NULL, /* no Subitem list for Subitems V 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText23 * i 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Text", /* pointer to text */ 

NULL /* next IntuiText structure V 

>; 


struct Menuitem Subltemll = i 

&SubItem12, /* next Subitem structure V 
122,-8, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
81,10, /* hit box width and height */ 

ITEMTEXT-t-COMMSEQ-MTEMENABLEO'f-HIGHCOMP, /* Item flags */ 

0, /* each bit mutual ly-excludes a same-level Item V 

(APTR)&IText23, /* Item render (IntuiText or Image or NULL) V 

NULL, /* Select render V 

"X", /* alternate command-key V 

NULL, /* no Subitem list for Subltems */ 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText24 » i 

3.1, C0MPLEMENT, /* front and back text pens and draumode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Speichern", /* pointer to text V 

NULL /* next IntuiText structure V 

>; 
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struct Menultem Menul tem10 = i 

&HenuItefn11, /* next Menultem structure V 
0,11, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

137,10, /* hit box width and height V 

ITEMTEXT-MTEMENABLED-i-HIGHCOMP, /* Item flags */ 

0, /* each bit mutually-excludes a same-Level Item V 

(APTR)&IText24, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 

NULL, /* alternate command’key */ 

&SubItem11, /* Subitem List V 

OxFFFF /* filled in by Intuition for drag selections */ 


struct IntuiText lText25 = < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 

NULL, /* font pointer or NULL for defaults V 
•*IFF**, /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menultem Subltemlö s i 

NULL, /* next Subitem structure */ 

122,12, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 

81,10, /* hit box width and height V 

ITEMTEXT-i-COMMSEQ-i-ITEMENABLED-i'HIGHCOMP, /* Item flags V 
0, /* each bit mutual ly*excludes a same* Level Item V 

(APTR)&IText25, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 
«I«, /♦ alternate command-key V 

NULL, /* no Subitem list for Subitems */ 

OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText26 » < 

3.1, C0MPLEMENT, /* front and back text pens and drawmode */ 

1.1, /♦ XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"ASCII”, /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menultem SubltemlS » i 

&Subltem16, /* next Subitem structure V 
122,2, /* XY of Item hitbox relative 

to TopLeft of parent hitbox */ 

81,10, /* hit box width and height V 

ITEMTEXT-i-COMMSEQ-i-lTEMENABLEO'i'HIGHCOMP, /* Item flags V 
0, /* each bit mutual ly*excludes a same* Level Item V 

(APTR)&lText26, /* Item render (IntuiText or Image or NULL) V 
liuLL, /* Select render V 
"A”, /* alternate coiiiiiand*key V 
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NULL, /* no Subitem list for Subitems V 

OxFFFF /* fiUed in by Intuition for drag selections */ 


struct IntuiText IText27 = i 

3.1, C0MPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults */ 

"Text”, /♦ pointer to text V 

NULL /* next IntuiText structure V 


struct Menuitem SubltemK = < 

&SubItem15, /* next Subitem structure V 
122,-8, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
81,10, /* hit box width and height */ 

ITEMTEXT+COMMSEQ+ITEMENABLED+HIGHCOMP, /* Item flags V 
0, /* each bit mutually-excludes a same-level Item */ 

(APTR)&IText27, /* Item render (IntuiText or Image or NULL) */ 
NULL, /* Select render V 
"T", /* alternate command-key V 

NULL, /* no Subitem list for Subitems V 
OxFFFF /* filled in by Intuition for drag selections V 


struct IntuiText IText28 = i 

3.1, COMPLEMENT, /* front and back text pens and drawmode V 

1.1, /* XY origin relative to Container TopLeft V 
NULL, /* font pointer or NULL for defaults V 
"Laden", /* pointer to text V 

NULL /* next IntuiText structure V 


struct Menuitem Menultem9 « < 

&MenuItem10, /* next Menuitem structure V 
0,0, /* XY of Item hitbox relative 

to TopLeft of parent hitbox V 
137,10, /* hit box width and height V 

ITEMTEXt+ITEMENABLED+HIGHCOMP, /* Item flags V 
0, /* each bit mutual ly-excludes a same-level Item */ 

(APTR)&IText28, /* Item render (IntuiText or Image or NULL) V 
NULL, /* Select render V 

NULL, /* alternate command-key V 

&SubItem14, /* Subitem list */ 

OxFFFF /* filled in by Intuition for drag selections V 


struct Menu Menu1 = < 

&Menu2, /* next Menu structure V 
0,0, /* XY origin of Menu hit box 

relative to screen TopLeft V 
57,0, /* Menu hit box width and height V 

MENUENABLED, /* Menu flags */ 
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«Datei", !* text of Menu name V 
&HenuItefn9 /* Menultem linked list pointer V 


#define HenuList Menul 

struct NewWindow NewUindowStructure » C 

275,85, /* window XY origin relative to TopLeft of screen */ 

150,50, /* window width and height V 

0,1, i* detail and block pens V 

NULL, /* IDCMP flags V 

NULL, /* other window flags V 

NULL, /* first gadget in gadget list V 

NULL, /* custom CHECKMARK imagery */ 

"Your new window", /* window title V 
NULL, /* custom screen */ 

NULL, /* custom bitmap V 

5,5, /* minimum width and height */ 

640,200, /* maximum width and height */ 

WBENCHSCREEN /* destination screen type V 


/* end of PowerWindows source generation */ 


Struktur 3.35: PowerWindows Menu-Strip 


3.8.4.4 So verarbeitet man den Quelltext weiter 

Zugegeben, der Text ist sehr lang, aber PowerWindows hat das 
daraus gemacht. Leider läßt es sich nicht einstellen, daß z.B. für 
jede Struktur eine Zeile mit allen Daten generiert wird. 

Wir wollen uns als letztes ansehen, wie man den Text 
weiterbearbeiten kann. Zusätzlich zur Menu-Strip hat uns Po¬ 
werWindows noch eine NewWindow-Struktur erstellt. Wir hätten 
dieses Window natürlich auch einstellen können, sogar noch 
komfortabler als die Menüs. Wir bleiben jedoch bei den Menüs. 

Es wird immer eine IntuiText-Struktur zusammen mit einer Me- 
nuItem-Struktur definiert. Diese sind aus unerklärlichen Grün¬ 
den durchnumeriert. Möchte man jetzt durch das Programm 
welche ergänzen, müssen die Nummern geändert werden. Leider 
geben diese Nummern nicht viel her an Informationen. Schöner 
wäre es gewesen, wenn die Namen der Menüpunkte dort stehen 
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würden. Schließlich kann man mit diesen mehr verbinden, und 
das Einsetzen neuer Menüpunkte fällt leichter. 

Gut anrechnen kann man dem Programm die Kommentare, ob¬ 
wohl sie in Englisch sind. Auch bei späteren Änderungen weiß 
man sofort, wofür der Parameter stand. Das ist besonders wich¬ 
tig bei Strukturen, die viele Null-Parameter haben. Dann vergißt 
man doch leicht, welche Bedeutung damit verknüpft war. Man 
muß zugeben, daß die Koordinatenauswahl ziemlich eigenwillig 
ist. Da wird auf "Pixel und Pfennig" gerechnet. Sie müssen später 
für mehr Platz systematisch alle Strukturen verändern. Viel Spaß! 

Beim ersten Untermenü des dritten Menüs (Grafik) müssen noch 
die beiden Grafiken eingesetzt werden. Entfernen Sie dafür die 
IntuiText-Strukturen, und setzen Sie die Image-Strukturen ein. 
Nicht vergessen, das Flag ITEMTEXT zu entfernen! 

Hinweis: Als abschließende Bemerkung möchte ich mir erlau¬ 
ben, Ihnen zu raten, möglichst wenig Änderungen 
auf einmal durchzuführen. Es hat sich nämlich in 
der Praxis gezeigt, daß hier und dort immer ein 
Fehler auftritt und dieser dann später sehr schwer zu 
finden ist. Die einfachste Methode ist, den ganzen 
Programmtext auszudrucken und dann die geänderten 
Stellen mit Textmarkern zu markieren. Ist die Ope¬ 
ration gelungen, können Sie neue Änderungen vor¬ 
nehmen. Aber immer zwischendurch compilieren, 
damit Sie das Ergebnis vor Augen haben. 


3.9 Kontakt über das Con 80 le.Device 

Beim Arbeiten mit dem IDCMP fällt auf, daß nur Daten emp¬ 
fangen werden können. Man kann zwar selektieren, welche Da¬ 
ten gesendet werden sollen, ist jedoch immer auf das Empfangen 
beschränkt. 

Der IDCMP bietet für die Arbeit zwei Tastaturabfragen an. Die 
RAWKEY-Abfrage sendet immer den Tastatur-Code, ohne ihn 
auf irgendeine Art zu verändern. Die VANILLAKEY-Abfrage 
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übersetzt den Tastatur-Code nach der Tastaturtabelle. Somit 
kann sich das Programm jeder internationalen Tastaturbelegung 
anpassen. 

Es bleibt aber immer noch das Problem, daß keine Daten gesen¬ 
det werden können. Um auch dies zu ermöglichen, müssen wir 
auf das Console.Device zurückgreifen. Das Console.Device ist ein 
eigenständiges Gerät, mit dem wir Daten austauschen können. Es 
bietet sowohl den Datenempfang auf RAWKEY- als auch auf 
VANILLAKEY-Art des IDCMP. Außerdem bearbeitet Con¬ 
sole.Device die Ausgabe. Es können Texte ausgegeben werden, 
die unter Beachtung der Window-Maße bearbeitet werden. Da¬ 
mit ist z.B. gewährleistet, daß kein Wort am Zeilenende ab¬ 
geschnitten wird. 

Weiterhin arbeitet das Console.Device mit vielen Formatierungs¬ 
hilfen, es scrollt unsere Textausgabe, bearbeitet den Text gra¬ 
fisch und erstellt Nachrichten über herrschende Bedingungen. 


3.9.1 Aufbau der Kommunikationslenungen 

Wie für jedes Device, so müssen wir auch für das Con¬ 
sole.Device erst einen Read- und einen Write-Port aufbauen, 
über die wir dann mit lOStandardMessages kommunizieren kön¬ 
nen. Zum Erstellen der Ports und der StdIOs benötigen wir zwei 
Funktionen, die uns Exec zur Verfügung stellt. CreatePort() und 
CreateStdICX) rufen wir in der Open_All()-Routine auf. 

Zuerst der Port zum Schreiben von E>aten: 


ConsoleUritePort = CreatePortC'wgb-con-dev.write", OL); 
if ('ConsoleUritePort) 

printfC'Beim neuen WritePort hat etwas nicht geklappt!\n"); 

Close AllO; 

exit(FALSE); 

> 

ConsoleUriteHsg = CreateStdlO(ConsoleUritePort); 
if (!ConsoleUriteHsg) 

printfC'CreateStdIO für Urite wollte nicht so recht!\n"); 
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Close_All(); 

exit(FALSE); 

> 


Programmteil 3.15: Daten schreiben 

Das gleiche zum Lesen von Daten: 

ConsoleReadPort = CreatePort(**wgb-con-dev.read**, OL); 
if (!ConsoleReadPort) 
i 

printfC'Beim neuen ReadPort hat etwas nicht geklappt!\n"); 

Close_AU(); 

exit(FALSE); 

> 

ConsoleReadMsg = CreateStdlOCConsoleReadPort); 
if (!ConsoleReadMsg) 
i 

printf(“CreateStdlO für Read wollte nicht so recht!\n''); 

Close AllO; 

exit<FALSE); 

> 


Programmteil 3.16: Daten lesen 


Nachdem die beiden Datenleitungen stehen, kann das Device ge¬ 
öffnet werden. Zuvor müssen aber zwei Felder der 
lOStdRequest-Struktur initialisiert werden. Dies ist unüblich für 
das öffnen eines Device, wird aber beim Console.Device benö¬ 
tigt! 

ConsoleWriteMsg->io_Data = (APTR)FirstWindow; 

ConsoleWriteMsg->io_Length = sizeof(*FirstWindow); 

conDevErr * OpenOevice ("Console.devicc”, OL, 

ConsoleUriteMsg, OL); 

if (conDevErr) 
i 

printf<**OpenDevice machte Schwierigkeiten!\n"); 

Close AllO; 
exit(FALSE); 

>; 


ConsoleReadMsg‘>io_Device = ConsoleWriteMsg->io_Device; 
ConsoleReadMsg->io_Unit = ConsoleWriteMsg‘>io_Unit; 


Programmteil 3.17: Device öffnen 
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Die ConsoleWriteMsg-Struktur wird damit auf ein Window fi¬ 
xiert, über das jetzt der Datenaustausch gehen soll. Nach dem 
öffnen wird auch die ConsoleReadMsg-Struktur mit dem Device 
und der Unit versehen. Jetzt kann die Ein- und die Ausgabe ge¬ 
startet werden. 

Alle Tastatureingaben, die zu dem spezifizierten Window laufen, 
werden zum Console.Device geleitet und dort verarbeitet. Erst 
dann bekommt das Programm eine Nachricht vom Console.De¬ 
vice, die die aufbereiteten Tastatur-Codes enthält. 

Will man irgendwelche Nachrichten an das Console.Device 
schicken, dann verwendet man die ConsoleWriteMsg-Struktur. 
Über sie richten wir Befehle und Anweisungen an das Device, 
wovon es einige gibt. 


3.9.2 Wir empfangen die ersten Daten 

Von dem Aufbau zur Datenleitung bis zum Empfangen von Da¬ 
ten ist es kein weiter Weg. Jetzt können wir schon die ersten 
Daten, d.h. Tastatureingaben, empfangen. Aber wie läuft das ab? 

Dazu müssen wir an das Console.Device die Nachricht senden, 
daß wir über eine bestimmte Anzahl von Tastatureingaben in¬ 
formiert werden möchten. Diese Anweisung wird mit einer 
StandardRequest-Struktur losgeschickt. Das Programm wartet 
aber nicht, bis es eine Antwort erhält, denn in der Zeit könen ja 
andere Dinge erledigt werden. 

Das einfachste wird es sein, wenn man für den Auftrag, Tasten 
zu lesen, eine Funktion schreibt. Diese Funktion wird in der 
Fachliteratur mit QueueRead() bezeichnet. Weil dies hier ein 
Fachbuch ist, werden wir es ebenso tun. 
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^*************************************** 
* * 

* Funktionen: Eingabe über ConsoleDev * 

★ * 

* Autor: Datum: Kommentar: * 

★ __ _ ★ 

* Wgb 24.10.1987 Verbesserte L&D * 


* StdReq Zeiger auf lOStdReq 

* buffer Adresse des Textpuffers 

* length Länge des Textpuffers 


***************** 


* 

* 

* 

* 

***y 


QueueRead(StdReq, buffer, Length) 

struct lOStdReq *StdReq; 
char *buffer; 

ULONG length; 

i 

StdReq*>io_Command = CMD_READ; 
StdReq->io~Data = (APTR)buffer; 
StdReq->io Length = length; 
SendlO(StdReq); 

> 


Funktion 3.11: Daten vom Console,Device lesen 

Der Funktion übergeben Sie den Zeiger auf die lOStdReq- 
Struktur, die wir zum Schreiben eingerichtet haben. Außerdem 
übergeben Sie den Zeiger auf einen Puffer, in dem die empfan¬ 
genen Daten später abgelegt werden, und zum Schluß noch die 
Länge des Puffers bzw. die Anzahl der Zeichen, die empfangen 
werden sollen. 

QueueRead(consoleReadHsg, &Buffer[0], 1L); 

Jetzt kann sich unsere Abfrageschleife "auf die Lauer legen" und 
darauf warten, daß über GetMsg(ConsoleReadPort) eine Er¬ 
folgsmeldung kommt. Dann tritt eine neue Abfrage in Aktion: 

if (GetMsgCconsoleReadPort)) 

Write(con8oleWriteMsg, &Buffer[0], 1L); 
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Es wäre besser, wenn man vor der Ausgabe das Zeichen noch 
auf Steuer-Codes testen würde, aber wir gehen zuerst den ein¬ 
fachen Weg und geben das Zeichen gleich wieder über das 
Console.Device aus. 


3.9.3 Wie läuft nun die Ausgabe? 


Auch dafür nimmt man eine Funktion. Diese arbeitet grundsätz¬ 
lich wie die Lese-Funktion: Wieder wird ein lOStdReq ausge¬ 
füllt, die Option Schreiben wird angewählt, der Textpuffer 
übertragen und die Länge eingesetzt. Dann wird die Nachricht 
losgeschickt. Es wird aber so lange gewartet, bis alles abgelaufen 
ist. So können keine Überlappungen entstehen. 


y*************************************** 

* * 

* Funktionen: Ausgabe über ConsoleDev * 

* sss====s==r=rs===s===:======ssss==== * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ __ * 

* Wgb 23.10.1987 Grundlage L&D * 

* * 

* StdReq Message Port der Nachricht * 

* Zeichen Anzahl der Zeichen * 

* * 

*w*************************************y 


ConWriteCStdReq, Text, Laenge) 

struct lOStdReq *StdReq; 
char Texte]; 
int Laenge; 


i 

StdReq->io_Command = CM0_WRITE; 
StdReq->io_Data = (APTR)Text; 
StdReq->io_Length = Laenge; 

DoI0(StdReq); 

> 


Funktion 3JZ‘ Daten über das ConsoleJOevice schreiben 
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Mit dem obigen Aufruf dieser Funktion wird das Zeichen am 
Pufferbeginn ausgegeben. Wir können auch einen String ausge¬ 
ben, der ja bekanntlich durch ein Null-Byte gekennzeichnet ist. 

Hierfür verwendet man die Längenangabe -IL. Ließe man dieses 
Programm laufen, Intuition-Library öffnet ein Window, Abfra¬ 
geschleife auf Close-Gadget, Console.Device mit Ein- und Aus¬ 
gabe, dann erhielte man schon einen Full-Window-Editor. Pro¬ 
bieren Sie es aus! 


3.9.4 Die Steuersequenzen des Console.Device 

Im Gegensatz zu dem IntuiText-Strukturen können beim Con¬ 
sole.Device auch Steuersequenzen übermittelt werden, die Ein¬ 
stellungen verändern oder Aktionen auslösen. Diese Steuerse- 
quenzen bestehen aus einfachen Zeichen-Codes oder komplexe¬ 
ren Zeichenketten. Sie brauchen nur mit der Schreibanweisung 
losgeschickt zu werden, und bei manchen bekommt man sogar 
noch eine Nachricht zurück. 

Sehen Sie in der ersten Tabelle die Steuerzeichen, die vollkom¬ 
men alleine stehen und sehr einfache Aktionen auslösen: 


Bezeichnung 

Zeichensequenz 

Kommentar 

Backspace 

0x08 

Entferne Zeichen links vom Cursor. 

Wie Backspace-Taste. 

Linefeed 

OxOA 

Bewege Cursor eine Zeile tiefer unter 
Berücksichtigung der Mode-Funktion. 
Nächste Zeile, aber nicht erste Spalte. 

Vertical Tab 

OxOB 

Bewege Cursor eine Zeile hoch. 

Form Feed 

OxOC 

Lösche Fensterinhalt. 

Carriage Return 

0x00 

Bewege Cursor in erste Textspalte. 

Nur in erste Spalte, nicht Zeile tiefer. 

ShifI In 

OxOE 

Schalte Shift Out aus. 

(Textmodus) 

Shift Out 

OxOF 

Shifte alle Zeichen, d.h. setse Bit 7 
aller Character-Codes. 

(Grafikmodus) 
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Bezeichnung Zeichensequenz 

Kommentar 

ESC 

0x1 B 

Escape. 

Einleitung zu Escape-Sequenzen 
(wird mehr bei Druckern benutzt). 

CSI 

0x9B 

control sequence introducer. 

Einleitung zu Control-Sequences 
(bei Console.Device, siehe unten). 

Tabelle 3.20: Einfache Steuerzeichen 


Wichtig sind die letzten beiden Zeichen. CSI leitet eine Steuerse¬ 
quenz ein und ist deshalb sehr wichtig, ESC wird für ähnliche 

Aufgaben benutzt. 



Bezeichnung 

Zeichensequenz 

Kommentar 

Reset 

ESC 0x63 

In den Urzustand bringen. 

Insert [n] Characters 

CSI [n] 0x40 

Füge [n] Zeichen ein. 

Wenn kein [n] angegeben, dann n = 1. 

Cursor Up [n] Lines 

CSI [n] 0x41 

Bewege Cursor [n] Zeilen nach oben. 
Wenn kein [n] angegeben, dann n = 1. 

Cursor Down [n] Lines 

CSI [n] 0x42 

Bewege Cursor [n] Zeilen nach unten. 
Wenn kein [n] angegeben, dann n = 1. 

Cursor Forward [n] Characters 

Bewege Cursor [n] Zeichen n. rechts. 


CSI [n] 0x43 

Wenn kein [n] angegeben, dann n = 1. 

Cursor Backward [n] Characters 

Bewege Cursor [n] Zeichen n. links. 


CSI [n] 0x44 

Wenn kein [n] angegeben, dann n = 1. 

Cursor Next Line [n] 

CSI [n] 0x45 

Bewege den Cursor in Zeile [n]. 

Wenn kein [n] angegeben, dann n = 1. 

Cursor Preceding Line [n 

1 

CSI [n] 0x46 

Bewege Cursor in verherg. [n] Zeile. 
Wenn kein [n] angegeben, dann n = 1. 

Move Cursor To Row [n] 

(Column [m]) 

Cursor in Zeile [n] (Spalte [m]). 


CSI [n] (0x3B 

[m]) 0x48 

Erase To End Of Display 

CSI 0x4A 

Lösche Fenster bis zum Ende. 

Erase To End Of Line 

CSI 0x4B 

Lösche bis zum Ende der Zeile. 

Insert Line 

CSI 0x4C 

Füge eine Zeile ein. 

Delete Line 

CSI 0x4D 

Lösche eine Zeile. 

Delete Character [n] 

CSI [n] 0x50 

Lösche Zeichen rechts vom Cursor. 
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Bezeichnung 
Scroll Up [n] Lines 

Scroll Down [n] Lines 

Set Mode 

Reset Mode 

Device Status Report 


Zeichensequenz Kommentar 


Schiebe Text um [n] Zeilen hoch. 

CSI [n] 0x53 

Schiebe Text um [n] Zeilen runter. 

CSI Cn] 0x54 

Mache Linefeed zu Return-Linefeed. 
CSI 0x32 0x30 0x68 

Setze Linefeed nur als Linefeed. 

CSI 0x32 0x30 0x6C 

Frage nach einem Statusbericht. 

CSI 0x36 0x6E 


Tabelle 3.21: Kombinierte Steuerzeichen 


Es seien noch einige Anmerkungen zu den kombinierten Steu¬ 
erzeichen gestattet. Diese unterscheiden sich von den einfachen, 
da sie aus mehreren Zeichen zusammengesetzt werden. Aber die 
zweite Gruppe läßt sich noch weiter unterscheiden. Wir finden 
nämlich überall einen Zahlenwert. Dieser wird in ASCII-Ziffern 
übergeben und nicht als ASCII-Code eingesetzt (Achtung!). Das 
ist untypisch für die konventionelle Datenübertragung. 

In allen Fällen, in denen eine Zahl eingesetzt werden kann, ist es 
auch möglich, diese wegzulassen. Dann nimmt das Con- 
sole.Device einen Standardwert, der auch in der Tabelle angege¬ 
ben ist. Manche der Kommando-Sequenzen fordern das Con- 
sole.Device auf, eine Nachricht zurückzugeben. Diese Nachricht 
enthält dann angeforderte Informationen, wie z.B die Cursor- 
Position. 

Weil alle Steuersequenzen an das Console.Device aus mehreren 
Zeichen bestehen, ist es ratsam, sich dafür ein Feld einzurichten, 
auf das man zurückgreift, wenn man eine Sequenz braucht. Bei 
der Abfrage gilt zuerst eine grundsätzliche Unterscheidung zwi¬ 
schen normalen Zeichen wie Buchstaben oder Zahlen und Son¬ 
derzeichen. Die Sonderzeichen sind in weitere Gruppen zu un¬ 
terteilen. Hier benötigt man zusätzliche Abfragen der Cursor- 
Tasten, der Funktionstasten und der mit CSI eingeleiteten 
Steuersequenzen, die man zurückbekommt. Hier ist zuerst ein 
Beispiel für wichtige Sonderzeichen und eine Kommandotabelle: 
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#define SPACE 0x20 

#define BACKSPACE 0x08 

«define LINEFEED OxOA 

#define RETURN 0x00 

#define CSI 0x9B 

#define DEVICE STATUS_REPORT 0x36, 0x6E 

#define WINDOW_STATUS_REQUEST 0x30, 0x20, 0x71 

#define CURSOR UP 0x41 

«define CURSOrIdOUN 0x42 

#define CURSOR Shift_UP 0x54 

#define CURSOR~Shift DOWN 0x53 


UBYTE Sonderzeichen[] = 

C 

SPACE, 

BACKSPACE, 

LINEFEED, 

RETURN, 

CSI, DEVICE_STATUS_REPORT, 
CSI, WINDOW_.STATUS__REQUEST 

>; 


Programmteil 3.18: Steuerzeichendefinition 


3.9.5 Auswertung aller Nachrichten vom Console.Device 

Die Kommunikation ist ausgereift: Wir können über zwei Ports 
Daten senden und empfangen. Wir wissen, welche "normalen" 
Zeichen empfangen werden können und welche Steuersequenzen 
es gibt. Damit sind wir gut gerüstet für einen Datenempfang. 
Nur gilt das auch für unser Programm? 

Das Empfangen einfacher Tastenanschläge stellt kein Problem 
für ein Programm dar. Kompliziert wird die ganze Sache, wenn 
eine Nachricht aus mehreren Zeichen besteht. Dann liegt die 
Gefahr in der Luft, daß man die Nachricht falsch interpretiert 
oder gar verstümmelt auswertet. Diesem Fehler wollen wir gleich 
von Anfang an Vorbeugen und eine hieb- und stichfeste Aus¬ 
wertung schreiben. Damit diese Auswertung auch einen Sinn hat, 
stellt sie den Grundstock für einen Editor dar. Dieser Editor 
wird soweit erweitert, daß er das alte NewCLI-Window ablösen 
kann. Weil wir uns aber zuerst nur mit der Abfrage beschäftigen 
wollen, setzen Sie bitte voraus, daß wir einen genügend großen 
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Textpuffer für das ganze Window haben. Zuerst benötigen wir 
eine Abfrageschleife, die aus unserem Datenpuffer Daten holt: 

if (GetHsg(consoleReadPort)) 
i 

switch (BufferCO]) 
i 

/* Untersuchung */ 

> 

QueueRead(consoleReacMsg, &Buffer[mode], 1L); 

> 


Programmteü 3.19: Abfrage Console.Device 


Wie immer hat die Abfrageschleife einen ganz primitiven 
Grundaufbau: nachsehen, ob Daten vorhanden sind, erstes Zei¬ 
chen untersuchen, neues Zeichen holen. Angenommen, es han¬ 
delt sich um einen Buchstaben oder ein normales Zeichen, das 
nicht gesondert behandelt werden muß, dann kann es folgende 
Zeilen bearbeiten: 

default : ConUriteChr(consoleWriteMsg, &Buffer[0]); 

Coords = FALSE; 

WindowBufferCy][x-13 = BuffertO]; 
if (WindowBufferEy][79] < x) 

WindowBuffer[y][79] = x; 
break; 

Frogrammteil 3.20: Allgemeine Tastenauswertung 


Die kleine Bearbeitungsroutine gibt zuerst das Zeichen aus. Dann 
wird das Koordinaten-Flag auf FALSE gesetzt, damit das Pro¬ 
gramm weiß, daß die aktuellen Koordinaten nun nicht mehr be¬ 
kannt sind. Als nächstes wird das Zeichen in den Window-Puf¬ 
fer übertragen. Dieser speichert alle Zeichen, die im Window zu 
sehen sind. Als nächstes wird geprüft, ob das neue Zeichen die 
Zeile verlängert. Wenn ja, wird die neue Zeilenlänge übertragen. 

Diese Methode wurde aus folgendem Grund gewählt: Ganz zu 
Anfang wird der Window-Puffer gelöscht. Er enthält dann nur 
Leerzeichen (0x20). Würde in einer Zeile Return getippt werden, 
dann soll diese ja an das DOS übergeben werden, damit der 
CLI-Befehl ausgeführt werden kann. Werden aber auch alle 
Leerzeichen an das DOS übergeben, dann kann es nicht erken- 
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nen, wo der Befehl abgeschlossen wurde. Dadurch ist es nicht 
möglich, einen Befehl zu senden, um z.B. sein Format zu erfah¬ 
ren, denn dafür darf nur das Befehlswort ohne jedes weitere 
Zeichen übermittelt werden. 

Apropos Bestätigung einer Zeile. Hier haben wir das erste Zei¬ 
chen, das gesondert betrachtet werden muß. Denn dann soll ja 
die Zeile, in der sich der Cursor befindet, an das CLI übermit¬ 
telt werden: 

case RETURN : ConUriteChrCconsoleUriteMsg, &Buffer[0]); 

ConUriteChr(consoleWriteMsg, &Sonderzeichen[2]); 

Coords = FALSE; 
if <WindowBuffer[y][79] 1= 0) 

< 

UindowBufferCy] [WindowBuffer[y] [79]] NULL; 
Execute(&WindowBuffer[y][0], 0, 0); 

WlndowBuffer[y][WindouBuffer[y][78]] - 0x20; 

> 

break; 

Programmteil 3.21: Return-Auswertung 

Diese zweite Routine zur Zeichenauswertung bearbeitet zuerst 
die Grafik. Das heißt, es wird zuerst der Cursor an den Zeilen¬ 
anfang und in die nächste Zeile gebracht. Wieder wird das Ko- 
ordinaten-Flag gesetzt. Danach prüft eine Abfrage, ob in der 
Zeile überhaupt Zeichen eingegeben wurden. Wenn ja, wird 
diese Zeile mit Null abgeschlossen, um an die £xecute()-Funk- 
tion des DOS übergeben werden zu können. Nachher wird der 
Abschluß wieder mit einem Space "übertüncht". 

Das letzte Zeichen, das gesondert betrachtet werden muß, ist das 
der Backspace-Taste. Weder die grafische Ausgabe wird vom 
Console.Device erledigt noch die Korrektur des Puffers. 

case BACKSPACE : ConUriteChrtconsoleUn'teMsg, &Buffer[0]); 

ConUritetconsoleUriteMsg, &Sonderzeichen[0], 2); 
UindowBufferty][x-1] > SPACE; 

Coords > FALSE; 
break; 


Progranmueü 3.22: BACKSPACE-Auswermng 
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Naja, eine Beschreibung brauchen Sie hoffentlich nicht dafür! 

Das letzte und zugleich wichtigste Problem, die Verwaltung der 
Steuersequenzen, wird verschoben. Wir helfen uns mit der fol¬ 
genden "Auswertung": 

case CSI : mode 1; 

break; 

Programmteil 3.23: CSI-Erkennung 

Diese Abfrageschleife setzt einfach einen Zähler, der später ab¬ 
gefragt wird, um eins höher. Aus dem Zähler läßt sich erken¬ 
nen, wie viele Zeichen noch zu bearbeiten sind. Es kann deshalb 
auftreten, daß mehrere Steuersequenzen im Puffer bereitliegen, 
weil auch die Funktions- und Cursor-Tasten mit dem CSI ge- 
handhabt werden. Aber sehen wir uns gleich die Abfrage dazu 
an: 


y********************************* 


Behandlung der Steuer- 
Sequenzen 


*********************************^ 


eise 1f (mode) 
i 

/* Abfrage */ 
mode = 0; 

QueueRead(consoleReadMsg, &BufferCmode], 1L); 

> 

Programmteil 3.24: Steuerzeichenbehandlung 

Das Else bezieht sich auf den If-Befehl, der den Console-Puffer 
auf ein Zeichen vom Device testet. Solange nämlich Nachrichten 
vorliegen, werden diese erst in den Puffer geholt, denn das 
Console.Device speichert nur die letzten 32 Zeichen. Stehen 
mehr Zeichen in der Warteschlange, dann werden diese einfach 
ignoriert. Deshalb wird die Variable mode verwendet, um immer 
neu eintreffende Zeichen in die nächste Stelle unseres Puffers 
einzutragen. 
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Betrachten wir jetzt die erste Auswertung einer Steuersequenz. 
Es handelt sich dabei um die Nachricht der Cursor-Position: 


y********************************* 


Control Sequence 


CURSOR POSITION REPORT 


* 
* 

* * 


if (Buffer[mode-1] == 82) 

< 

Coords = TRUE; 

X = 0; y = 0; i = 1; 

while (Buffer Ci] < 0x3A & 0x2F < Buffer Ci]) 
< 

y *= 10; 

y += Buffer Ci] - 0x30; 
i ++; 

> 

i ++; 

while (Buffer Ci] < 0x3A & 0x2F < Buffer Ci]) 
< 

X *= 10; 

X += Buffer Ci] - 0x30; 
i ++; 

> 

> 


Programmteil 3.25: Cursor-Position auswerten 

Der Programmteil geht ein Zeichen nach dem anderen durch 
und berechnet daraus die X- und Y-Koordinate. Der DEVICE 
STATUS REPORT hat das Format: CSI Reihe; Zeile R, Wir er¬ 
kennen ihn also an dem abschließenden R. Dann wird der Puffer 
Zeichen für Zeichen ausgewertet. Die Berechnung des ersten 
Wertes schließt ab, wenn das Programm auf ein Semikolon trifft. 
Danach kann der X-Wert berechnet werden. Wichtig ist auch, 
daß das Koordinaten-Flag wieder gelöscht wird. Denn später 
folgt ein Test, der bei gesetztem Flag die Nachricht ans Con- 
sole.Device schickt, daß es doch bitte die Koordinaten auf die 
Datenleitung legen soll. Dann hätten wir eine Endloskommuni¬ 
kation, die aus den Koordinaten des Cursors bestehen würde. 
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Die nächsten Überprüfungen gehen davon aus, daß immer noch 
eine Control Sequence vorliegt. Allerdings nicht der DEVICE 
STATUS REPORT. Zuerst wird überprüft, ob vielleicht die 
Cursor-Tasten betätigt wurden. Das Console.Device erlaubt de¬ 
ren Benutztung auch mit Shift. Dann wird nicht die Position des 
Cursors geändert, sondern der ganze Fensterinhalt gescrollt. 
Dieses Scrollen muß natürlich auch im Textpuffer geschehen. 
Aber betrachten Sie vorher die Abfrage: 


eise 

i 

switch (Buffer[mode-1]) 
< 


y********************************* 
* * 


Control Sequence 


SHIFTED CURSOR HOVE 


*********************************^ 


case CURSOR^Shift^UP : Move^DownO; 

break; 

case CURSOR.Shift^DOWN : Move^UpO; 

break; 


Control Sequence : 


NORMAL CURSOR HOVE 


********************************* y 


case CURSOR^UP 
case CURSOR^DOWN 
> 


if (y == 1) Move_Down(); 
break; 

if (y == Ymax) Move_Up(); 
break; 


Programmteil 3.26: Cursor-Tasten auswerten 

Die letzten beiden Vergleiche gehen auf normale Cursor-Tasten¬ 
bewegungen ein. Denn wenn der Cursor den oberen oder unte¬ 
ren Rand erreicht hat, wir auch hier gescrollt. Für das Scrollen 
des Window-Puffers wurden eigens zwei neue Funktionen defi- 
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niert. Sie stehen in Zusammenhang mit den Textpuffer-Funktio¬ 
nen. Hier sind sie gleich alle: 


* * 

* Funktionen: Textpufferbearbeitung * 

* SS=3:===SS==SS=S=SSS====SS====SS==S= * 

* * 

* Autor: Datum: Kommentar: * 

★ _ _ _ ♦ 

* Wgb 2.11.1987 * 

* * 

* y Nummer der Zeile ♦ 

* X Nummer der Spalte * 

* * 

***************************************y 


Clear_Buffer() 

< 

int y; 

for(y=0; y<80; y ++) 
Clear Line(y); 

> 


Clear_Line(y) 
int y7 
i 

int x; 

for<x=0; x<79; x ++) 

WindowBufferCy]Cx] = 0x20; 

UindowBufferCy][78] = NULL; /* Zeilenendekennung V 
WindowBufferCy][79] = NULL; /* Anzahl eingegebener Zeichen */ 
> 


Move UpO 

r 

int X, y; 

for(y=1; y<80; y +■►) 
for(x=0; x<80; x ++) 

WindowBuffer[y-1] [X] = UindowBuffer[y] [x]; 
Clear Line(79); 

> 


Move DownO 

r 

int X, y; 

for(y=79; y>0; y --) 
for(x=0; x<80; x ++) 

UindowBuffer[y] [X] = WindowBuffer[y-1][x]; 
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Clear_Line<0); 

> 


Funktion 3.13: Pujferbehandlung 


Clear_Buffer( ) 

Wird zu Anfang des Programms aufgerufen und initialisiert den 
Puffer wie schon besprochen. Die Anzahl der eingegebenen 
Zeichen pro Zeile wird auf Null gesetzt, genauso wie auch das 
Zeilenende durch eine Null gekennzeichnet wird. 


Clear_Line( ) 

Die eigentliche Routine, die von Clear_Buffer() aufgerufen 
wird. Dadurch ist es möglich, Zeilen selektiert zu löschen, was 
ja mit Steuersequenzen unterstützt wird. 


Es ist nicht möglich, die Abfrage und Behandlung aller mögli¬ 
chen Steuersequenzen in diesem Kapitel zu beschreiben. Deshalb 
folgt als letztes einen allgemeiner Abschnitt, der alle unbehan¬ 
delten Routinen zur Ausgabe weitergibt. Damit unterschlagen 
wir nichts, und das Console.Device ist zufrieden. 


^********************************* 

* * 

* 

* Handhabung jeder Sequenz * 

* * 

*********************************^ 


Control Sequence : 
Handhabung jeder Sequenz 


ConUriteCconsoleUriteHsg, &Buffer[0], mode); 
Coords = FALSE; 

> 


Programmteil 3.27: Durchschleifen jeder Sequenz 


Wer Lust hat, kann aber gerne zu allen weiteren Steuersequenzen 
Abfragen schreiben. Es ist z.B. noch nicht beschrieben worden, 
wie man eine einfache Funktionstastenbehandlung realisiert. Das 
ist aber ganz einfach. Vorausgesetzt, Sie nehmen unveränderbare 
Belegungen, dann richten Sie einfach ein Pointer-Feld mit den 
gewünschten Texten ein. Hier ein Beispiel für den CLI-Editor; 
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UBYTE *Funktionstasten[] = 
i 

"clir"+RETURN, 

"cd df1:"+RETURN. 

"cd sys;"+RETURM, 

"list'HRETURN, 

"makedir ram:c"+RETURN+"copy sys:c ram:c"+RETURN, 
"execute make " 

>; 


Programmteil 3.28: Funktionstasten-Definiäon 

Die Abfrage für die Funktionstasten muß diese nur über 
identifizieren und die Nummer berechnen. Dann kann der Poin¬ 
ter an ConWriteO; übergeben werden: 

ConUritetconsoleUriteMsg, Funktionstasten[Nunmer], -1L); 


3.9.6 Zum Schluß der CU-Editor 

Für die Arbeit zwischen Intuition, dem Window des Editors, und 
dem Console.Device wird empfohlen, das Console.Device auf 
eine etwas andere Art zu öffnen. Ich möchte auch diese hier 
kurz beschreiben: 

Abwohl das Console.Device in den IDCMP eingebaut wurde, 
sind doch dadurch nicht alle Möglichkeiten ausgeschöpft. Für 
eine totale Offenheit in der Bedienung müssen wir zuerst eine 
lOStdReq-Struktur definieren, in die wir den Zeiger auf unser 
Window im Wert io_Data "einpflanzen". Danach kann das Device 
wie gewohnt geöffnet werden. Jetzt ist es mit unserem Intuition- 
Window verbunden, und die Kommunikation kann über die 
verwendete Struktur abgewickelt werden. Sie können sie sowohl 
zum Schreiben als auch zum Lesen verwenden. Die Lese- und 
Schreibfunktionen, die am Anfang des Kapitels dafür entwickelt 
wurden, gelten nach wie vor. 

Setzen Sie jetzt alle Abfrageelemente, alle Routinen zum öffnen 
und Schließen und die Textpufferbehandlung zusammen. Ver¬ 
gessen Sie nicht, die nötigen Variablen und Felder zu definieren! 
Fertig! Ein neuer CLI-Editor! 
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Hinweis: In diesen Editor können Sie auch das vorher im 

Buch beschriebene Gadget einbauen, das die Größe 
des Editorfensters ändert. 


3.10 Einrichten selbstdefinierter Tastaturtabeiien 

Immer wird davon gesprochen, daß das Console.Device die 
RAWKEY-Codes in Zeichen umwandelt. Nun fragt sich aber 
der aufmerksame Programmierer, nach welchen Anweisungen, 
Befehlen oder Definitionen diese Umwandlung geschieht. 

Für die Transferierung der RAWKEY-Codes zu richtigen Zei¬ 
chen wird eine aufwendige Tabelle verwendet. Das ist die sog. 
Tastaturtabelle. In ihr ist genauestens verzeichnet, was bei wel¬ 
chem Tastendruck wie umgewandelt werden soll. 

Diese Tastaturtabelle ist noch weiter unterteilt. Sie enthält Ab¬ 
schnitte für die Shift-, Alt- oder Ctrl-Taste. Außerdem wird die 
CapsLock-Taste noch gesondert behandelt. Das macht es z.B. 
möglich, daß bei einer deutschen Tastaturbelegung nur die 
Buchstaben geshiftet werden und nicht die Sonderzeichen oder 
die Zahlen. 

Durch die Tastaturtabellen ist es uns auch möglich, auf eine Ta¬ 
ste einen ganzen Text zu legen. Dieser kann aus normalen Zei¬ 
chen bestehen oder auch mit lauter Steuer-Codes belegt werden. 

Sie sehen, welche Möglichkeiten das Console.Device zur Verfü¬ 
gung stellt. 


3.10.1 Aufbau der Tastaturtabellen 

Wir wissen jetzt, daß die Übersetzung der RAWKEY-Codes 
über Tastaturtabellen abgewickelt wird. Aber wie sind diese Ta¬ 
bellen aufgebaut, und welche Informationen enthalten sie genau? 

Das ist die Frage, die uns zuerst beschäftigen soll. 
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Wenn man von der Tastaturtabelle spricht, so meint man damit 
alle kleineren Tabellen, aus denen sich diese zusammensetzt. 

Für den Zusammenhalt aller Untertabellen ist die KeyMap- 
Struktur zuständig. Sie enthält nur Zeiger auf jede der kleineren 
Tabellen: 

struct KeyMap 
< 

0x00 00 UBYTE *kin LoKeyHapTypes; 

0x04 04 ULONG ‘knTLoKeyMap; 

0x08 08 UBYTE «küTLoCapsable; 

OxOC 12 UBYTE *lcnrLoRepeatable; 

0x10 16 UBYTE »IcnTHiKeyHapTypes; 

0x14 20 ULONG «knTHiKeyMap; 

0x18 24 UBYTE *kiii~HiCapsable; 

OxIC 28 UBYTE *kin~H{Repeatable; 

0x20 32 

>; 

Zuerst erkennt man, daß die KeyMap-Struktur in zwei große 
Teile zerfällt: einen Lo- und einen Hi-Abschnitt. 

Der erste ist für die Zeichen mit dem RAWKEY-Code vom 
0x00 bis 0x3F zuständig. 

Der zweite Abschnitt enthält Informationen zu den Codes von 
0x40 bis 0x67. Diese Teilung wurde vorgenommen, damit die 
Tastatur noch für weiteren Tasten frei ist, die dann in die Hi- 
Tabellen eingetragen werden können. 

Sehen Sie dazu noch einmal das RAWKEY-Schaubild an, dem 
Sie den Code jeder Taste entnehmen können. Gehen wir aber 
nun jede Tabelle einzeln durch: 

km_LoKeyMapTypes & km_HiKeyMapTypes 

Diese beiden Tabellen enthalten für jede Taste ein Byte. In die¬ 
sem Byte sind Flags untergebracht, die etwas über später fol¬ 
gende Informationen aussagen. Es ist leider nicht möglich, für 
jede Taste alle Kombinationen zu belegen. Das heißt. Sie können 
nicht zu jeder Taste einen normalen, einen Shift-, einen Alt- 
und einen Ctrl-Wert definieren. Weil auch die Kombinationen 
von zwei Qualifiers, so werden die Shift-, die Alt- und die 
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Ctrl-Taste genannt, berücksichtig wurden, können insgesamt nur 
vier Zeichen auf eine Taste gelegt werden. Allerdings können 
Sie bestimmen, welche Qualifier welche Zeichen auslösen. Oder 
Sie entscheiden sich für einen ganzen String auf der Taste, dann 
müssen Sie aber in Kauf nehmen, daß nur zwei Belegungen für 
die Taste zulässig sind. 



Dil 


3Ü3 



m 

m 


m 


Ql 



m 

m 

m 

B 

Ü 

m 

m 

i 


iB 

i 


Abbildung 3.13: Die RA W-Tastatur-Codes II 

km_LoKeyMap & kiii_HIKeyMap 

Hier haben wir jetzt die beiden Tabellen, die in ihren ULONG- 
Werten die Zeichen enthalten, die beim Tastendruck erscheinen 
sollen. Da der ULONG-Wert aus vier Bytes besteht, finden wir 
in jedem Byte den Code des Zeichens, das bei einer der vier 
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Kombinationen ausgegeben werden soll. Es sei denn, es handelt 
sich um einen String. Dann stellt der ULONG-Wert einen Poin¬ 
ter auf den String dar. 

km_LoCapsabIe & km_HiCapsable 

Diese beiden Tabellen enthalten keine Zeichen-Codes, die aus¬ 
gegeben werden sollen. In den Tabellen finden wir nur gesetzte 
und ungesetzte Bits für jeden RAWKEY-Code. So zeigt ein ge¬ 
setztes Bit an, daß diese Taste bei gedrückter CapsLock-Taste 
wie bei Shift behandelt werden soll. Ist das Bit nicht gesetzt, 
wird die Taste normal ausgegeben. 

km_LoRepeatable & kiii_HiRepeatable 

Die nächsten beiden Tabellen arbeiten genauso wie die 
Capsable-Tabellen. Auch hier haben wir wieder für jeden 
RAWKEY-Code ein Bit. Ist dieses gesetzt, dann wird die Taste 
nach dem Wert aus Preferences wiederholt. Wurde das Bit ge¬ 
löscht, dann wird die Taste nicht wiederholt. 


3.10.2 Die Arbeit mit den Tabeilen 

Ist es gewünscht, Einfluß auf die Tastaturtabelle zu nehmen, so 
ist es nötig, erst einmal den momentanen Stand zu erfahren. 
Diese Arbeit erledigt nicht eine neue Library, sondern es besteht 
ein Weg über das Console.Device. Immerhin kann man nur mit 
Tastaturtabellen arbeiten, wenn das Console.Device aktiv ist. 

Es existieren Kommandos, die an das Console.Device gesendet 
einen Report über den aktuellen Zustand geben. Ebenso wird es 
unterstützt, die Zeiger auf eine neue Tastaturtabelle zu übertra¬ 
gen. Leider werden die beiden Vorgänge nicht über Library-in¬ 
terne Funktionen erledigt. Die Aufträge werden ganz einfach 
mit einem lOStdReq übermittelt. Deshalb empfiehlt es sich, da¬ 
für eigene Funktionen zu schreiben. 

Das Kommando zum Holen der aktuellen KeyMap-Belegung 
heißt CD_ASKKEYMAP. Wir brauchen dazu die Größe und 
Adresse unserer KeyMap-Struktur, in die die Daten gelegt wer¬ 
den sollen. Danach kann der Request aufgerufen werden; 
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AskKeyMap(ConUriteRequest, OwnKeyHap) 

struct lOStdReq *ConUriteRequest; 
struct KeyMap *OwnKeyHap; 

C 

BYTE Error; 

ConWriteRequest’>io_Coninand = CD_ASICKEYMAP; 
ConWriteRec|uest->io_Lenght = sizeof(struct KeyMap); 
ConWriteRequest’>io_Data = &OwnKeyMap; 

Dol0(ConUriteRequest); 

Error = ConWriteRequest->io_Error; 

if (Error) 

return(FALSE); 

eise 

return(TRUE); 


Funktion 3.14: AskKeyMapQ 

Wir finden nach erfolgreichem Arbeiten der selbstdefinierten 
Funktion in der Struktur OwnKeyMap die Zeiger auf die akti¬ 
ven Tastaturtabellen. Diese können analysiert und beeinflußt 
werden. Mit dieser Methode kann man z.B. ganz einfach ein¬ 
zelne Zeichen der Tastatur ändern. 

Hat man aber eine sehr spezielle Belegung, die nicht mit weni¬ 
gen Änderungen aktivierbar ist, oder will man eine Tabelle la¬ 
den, dann eignet sich diese Methode nicht. Dafür geht man an¬ 
ders vor: Zuerst wird der Speicher mit den Tastaturwerten be¬ 
legt. Dies kann entweder im Programmtext oder durch Laden 
abgewickelt werden. Danach erstellt man die neue KeyMap- 
Struktur. Diese ist aber das Kernstück, aus dem das Con- 
sole.Device alle Informationen nimmt. Also müssen wir die neue 
KeyMap an das Console.Device übertragen. Dafür gibt es ein 
Kommando, und dieses läßt sich am einfachsten in einer eigens 
dafür entwickelten Funktion auf rufen: 

SetKeyMap(ConUriteRequest, OwnKeyMap) 

struct lOStdReq *ConUr1teRequest; 
struct KeyMap *OwnKeyMap; 

i 
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BYTE Error; 

ConUriteRequest->io_Coninand = CD_SETICEYMAP; 

ConWriteRequest->io_Lenght = sizeof(struct KeyHap); 
ConWriteRequest->io_Data = &OwnKeyMap; 

Dol0(ConWriteRequest); 

Error = ConWr iteRec|uest->io_Error; 

if (Error) 

returnCFALSE); 

eise 

return(TRUE); 


Funktion 3,15: SetKeyMap 

Im Prinzip ist das die gleiche Funktion wie die vorhergehende. 
Einziger Unterschied ist das Kommando. Wollen Sie beide 
Funktionen durch eine ersetzen, so ist das nicht unmöglich! Wir 
erweitern nur den Funktionsaufruf um einen Parameter: 

Beispiel: 

DoKeyMapCWriteRequest, KeyMapPointer, CD^SETKEYMAP) 

DoKeyMap(ConWriteRequest, OwnKeyHap, Mode) 

struct lOStdReq ♦ConWriteRequest,- 
struct KeyMap *OwnKeyMap; 

UWORD Mode; 

i 

BYTE Error; 

ConWr i teRequest'>io_Coninand = Mode; 

ConWriteRequest->io_Lenght = sizeof(struct KeyMap); 

ConWriteRequest*>io~Data = &OwnKeyMap; 

Dol0(ConWriteRequest); 

Error * ConWriteRequest->io_Error; 

if (Error) 

return(FALSE); 

else 

return(TRUE); 

> 


Funktion 3,16: DoKeyMap() 
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Mit dieser letzten Funktion ist es möglich, zwei weitere Kom¬ 
mandos anzusprechen: CD_ASKDEFAULTKEYMAP und 
CD_SETDEFAULTKEYMAP. Beide arbeiten genauso wie die 
beiden bekannten. Allerdings beeinflussen wir mit ihnen die 
Default-KeyMap, die jedem Programm beim öffnen des Con- 
sole.Device zur Verfügung steht. 

In dieser KeyMap werden alle Zeichen in die Gruppen Lo und 
Hi unterteilt. Die Lo-Gruppe wird folgendermaßen behandelt: 

Alle Tasten, die alleine gedrückt werden, erzeugen ihren 
ASCII-Code. 

Alle Tasten, die mit Shift gedrückt werden, erzeugen ihren 
geshifteten ASCII-Code. 

Alle Tasten, die mit Alt gedrückt werden, erzeugen ihren 
ASCII-Code, bei dem das höchste Bit (0x80) gesetzt ist. 

Alle Tasten, die mit Alt und Shift gedrückt werden, er¬ 
zeugen ihren geshifteten ASCII-Code, bei dem das höchste 
Bit (0x80) gesetzt ist. 

Alle Tasten, die mit Ctrl gedrückt werden, erzeugen ihren 
ASCII-Code, bei dem Bit 5 und 6 gelöscht werden. 

Die Hi-Gruppe der Default-KeyMap wird anders behandelt: 

Da in der High-KeyMap fast nur Steuertasten enthalten sind, 
besteht diese Tabelle nicht aus Einzel-Code. Wir treffen hier fast 
nur Strings an. Das ist auch der Grund, warum die Steuertasten 
höchstens zweifach belegt werden können. 


Taste Übersetzter Weit 

BACKSPACE 0x08 

ENTER 0x00 

DEL 0x7F 


Tabelle 3.22: Tasten ohne jeden Qualifier 
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Taste Wert ohne - 

Wert mit - 

Oualißer 


SPACE 

0x20 

OxAO 

Alt 



RETURN 

0x00 

OxOA 

Ctrl 



ESC 

0x1 B 

0x9B 

Alt 




0x20 

OxFF 

Alt 



TabeUe 3.23: 

Tasten mit einem Qualifier 




Taste 


Wert 


Wert mit Shift 

TAB 


0x09 


0x9B 

II2II 


UP 


0x9B 

«A« 

0x9B 

iijii 


DOWN 


0x9B 

iigii 

0x9B 

11311 


FORWARD 


0x9B 

«C” 

0x9B 

II gii 


BACKWARD 


0x98 

IIQII 

0x9B 

II All 


Fl 


0x9B 

*•0“ *• 

0x9B 

»10** 

II 

F2 


0x9B 

II 

0x9B 

»11** 

II 

F3 


0x9B 

112" II 

0x9B 

1112" 

II 

F4 


0x9B 

»•3" *• 

0x9B 

»13** 

II 

F5 


0x9B 

11^" II 

0x9B 

»14** 

II 

F6 


0x9B 

115" II 

0x9B 

»15“ 

II 

F7 


0x9B 

«6" ** 

0x9B 

»16“ 

II 

F8 


0x9B 

ii'T’*’ II 

0x9B 

»17“ 

II 

F9 


0x9B 

113" II 

0x9B 

»18“ 

II 

FlO 


0x9B 

119** II 

0x9B 

»19“ 

II 

HELP 


0x9B 

Ii 9 ~ II 




Tabelle 3.24: 

Tasten der High-KeyMap 





3.10.3 Eine Tastaturtabelle selber zusammensetzen 

Ihnen ist jetzt bekannt, aus welchen Einzeltabellen sich die Ta¬ 
staturtabelle zusammensetzt. Auch die Abfrage der bestehenden 
und das Setzen einer neuen Tabelle ist erklärt worden. Wie er¬ 
stellt man nun seine eigene Tabelle und auf was muß man ach¬ 
ten? Unter dieser Fragestellung werden wir dieses Kapitel be¬ 
schließen. 
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KeyMapTypes 

Als erstes benötigen wir die beiden Types-Tabellen. Diese ent¬ 
halten, wie oben schon besprochen, zu jeder Taste Flags, aus 
denen sich schließen läßt, ob es ein String oder vier Einzelzei¬ 
chen sind und mit welchen Qualifiern die Zeichen zu erreichen 
sein werden. Folgende Flags sind möglich; 


Name 

Wert 

Beschreibung 

KC_NOQUAL 

OL 

Ohne jeden Qualifler. 

KC_VANILLA 

7L 

Standardwert mit Ctrl. 

KCF_SHIFT 

0x01 L 

Gedrückte Shift-Taste. 

KCF^ALT 

0x02L 

Gedrückte Alt-Taste. 

KCF_CONTROL 

0x04L 

Gedrückte Ctrl-Taste. 

KCF^DOWNUP 

OxOSL 

Reagiert nur, wenn Taste niederge¬ 
drückt und losgelassen wurde. 

KCF^DEAD 

0x20L 

Taste reagiert nicht. 

KCF^STRING 

0x40L 

Taste gibt einen String aus. 


Tabelle 3.25: KeyMapTypes 

Wir können bei Auswahl der Types nun verschiedene Belegun¬ 
gen erreichen. Dabei haben die vier Bytes die folgenden Bedeu¬ 
tungen: 


Qualifier-Kombination 1. Byte 2. Byte 3. Byte 4. Byte 


KC_ 

_DEAD 

- 

- 

- 

- 

KC] 

”noqual 

- 

- 

- 

ohne 

KC] 

SHIFT 

- 

- 

Shift 

ohne 

KC' 

_ALT 

- 

- 

Alt 

ohne 

KC] 

CONTROL 

- 

- 

Ctrl 

ohne 

KC] 

_^ALT + KC__SHIFT 

Shift+Alt 

Alt Shift 

ohne 


KC_ 

_CONTROL + KC_ALT 

Ctrl-FAlt 

Ctrl Alt 

ohne 


KC_ 

_CONTROL + KC__SHIFT 

Ctrl+Shift Ctrl Shift 

ohne 


KC 

VANILLA 

Shift+Alt 

Alt Shift 

ohne 



Aufierdem ist noch Ctrl möglich. 
KC__STRING Pointer auf String 


Tabelle 3.26: KeyMapTypes^Kombinationen 
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Hiermit müßte es Ihnen schon möglich sein, für beliebige Bele¬ 
gungen eine Types-Tabelle zu erstellen. Das am häufigsten be¬ 
nutzte Qualifier-Flag ist KC_VANILLA, weil die üblichen Ta¬ 
sten Shift und Alt integriert sind. Aber zusätzlich wird auch 
noch Ctrl unterstützt, indem Bit 5 und 6 des NOQUAL-Wertes 
gelöscht werden. Durch geschickte Wahl kann man auch damit 
sehr gut zurecht kommen. 

KeyMap 

Eine Lo- oder Hi-KeyMap läßt sich jetzt sehr einfach zusam¬ 
menbauen. Allerdings empfiehlt es sich hier für C-Programmie- 
rer, in den Assembler-Modus des Quelltextes umzuschalten, da 
so das Problem viel einfacher zu lösen ist. Fertigen Sie dann 
einfach eine Tabelle an, die in Vierer-Gruppen unterteilt ist. 
Jede Gruppe entspricht einer Taste und ist nach der oben ste¬ 
henden Tabelle geordnet. Jedes Byte enthält ein Zeichen, das je 
nach Tastenkombination ausgegeben wird. 

Handelt es sich aber um einen String, so steht an dieser Stelle 
nicht eine Gruppe aus vier Bytes, sondern ein LONG-Wert, der 
den Zeiger auf unseren String darstellt. Leider wird nicht gleich 
auf einen String gezeigt, das wäre ja viel zu einfach. Der Pointer 
zeigt zuerst auf eine weitere Tabelle, die eigens für diese Taste 
die Werte enthält. Und zwar ist das zuerst die Länge des Strings, 
der bei normalem Tastendruck erscheinen soll, dann ein Offset 
vom Anfang der String-Tabelle zum eigentlichen String selbst. 
Als weiteren Wert finden wir die Länge des Strings, der bei ei¬ 
nem Tastendruck mit Shift ausgegeben werden soll. Auch dazu 
steht der Offset vom Beginn der Tabelle. 

Capsable 

Wie von der Schreibmaschine bekannt, hat auch die Amiga-Ta- 
statur eine CapsLock-Taste, die wie ein Dauer-Shift funktio¬ 
niert. Da die Tastatur aber einen Tastaturprozessor hat, wird 
nicht einfach nur ein Dauer-Shift simuliert. Wir haben es mit 
einer neuen Art der Shift-Taste zu tun. Für die CapsLock-Taste 
kann bestimmt werden, auf welche Tasten sie anwendbar ist und 
auf welche nicht. Diese Methode bietet den Vorteil, daß z.B. die 
Satzzeichen nicht geshiftet werden und dort ganz normal weiter- 
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geschrieben werden kann, ohne vorher den CapsLock-Modus 
aufheben zu müssen. 

Für alle Tasten haben wir 8 Bytes mit 64 Bits zur Verfügung. 
Jedes dieser Bits repräsentiert eine Taste: 

Bit 0 Byte 0 RAWCOOE 0x00, Bit 1 Byte 0 RAWCODE 0x01 ... 

Bit 0 Byte 1 RAUCOOE 0x08 ... Bit 7 Byte 7 RAUCODE 0x4F. 

Setzen Sie alle die Bits, für deren Tasten Sie eine Shift-Behand- 
lung wünschen. 

Repeatable 

Die gleiche Methode, die der Capsable-Tabelle zu Grunde liegt, 
wurde auch bei der Repeatable-Tabelle angewendet. Nur hier 
indiziert jedes gesetzte Bit, daß die Taste nach der Wiederho¬ 
lungszeit und der Wiederholfrequenz der Preference-Werte wie¬ 
derholt werden soll. So können manche Tasten von der 
Wiederholfunktion ausgeschlossen werden. Das ist sinnvoll, wenn 
eine Taste nicht mit Wiederholung gebraucht wird oder eine 
Wiederholung großen Schaden anrichten könnte. Meistens wird 
die Return-Taste von der Wiederholung ausgeschlossen. 


3.11 Speicherverwaltung 

Irgendwann kommt es bei Anwenderprogrammen immer vor, 
daß ein gewisser Speicher gebraucht wird. Die einfachste Spei¬ 
cherform sind die Variablen. Hier übersieht man schon bei der 
Programmgestaltung, welche benötigt werden. Die etwas kom¬ 
plexere Form davon bilden die Variablenfelder. Aber auch dabei 
ist man immer darüber informiert, welche Ausmaße diese haben 
werden. 

Doch schon hier setzt das Problem an. Es könnte für den Pro¬ 
grammablauf z.B. ein Variablenfeld doppelt genauer Zahlen 
benötigt werden. Dieses soll die Ausmaße 1000*1000 für die 
Farbwerte einer hochauflösenden Grafik haben. Unser Compiler 
wird dann im fertigen Programm l.OOO.OOOmal eine doppelt ge¬ 
naue Variable reservieren. Sie können sich vorstellen, welche 
Ausmaße das annimmt! 
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An einem kleinen Beispiel möchten ich Ihnen jetzt zeigen, wie 
Sie Speicherbereiche ganz individuell vom System holen und 
nach Gebrauch wieder zurückgeben. Drei Methoden der Spei¬ 
cherorganisation werden daran demonstriert. Das Beispiel selbst 
ist natürlich aus dem Themenkreis Intuition gewählt. Wir werden 
versuchen, uns vier Textpuffer für die entsprechenden String- 
Gadgets zuweisen zu lassen. 


3.11.1 Die Speicherorgahisatlon des Amiga 

Bevor ein Programm erstellt werden kann, sollte man sich mit 
der Speicherorganisation vertraut machen. Der Amiga hat eine 
zweigeteilte dynamische Speicherverwaltung. 

In dieser Tabelle finden Sie die Speicherbelegung: 


Adresse 

Belegung 

Kommentar 

0x00000000 

Chip-RAM 

Spiegelung des Kickstart-ROM 

0x08000000 


Dreimalige Spiegelung des Chip-RAM 

0x20000000 

8 MByte Fast-RAM 


OxAOOOOOOO 

CIAs 


OxCOOOOOOO 

512 KByte-Erweiterung 

(nur 500er Sc 2000er) 

0XC8000000 

Uhbenutst 


OxDCOOOOOO 

Echtseituhr 

(nur 500er Sc 2000er) 

OxDFOOOOOO 

Custom-Chips 


OxEOOOOOOO 

Unbenutzt 


0XE8000000 

Expansion - Slots 


OxFOOOOOOO 

ROM-Module 


0XF8000000 

Kickstart-ROM 

Spiegelung 

OxFCOOOOOO 

Kickstart-ROM 


Tabelle 3.27: 

Speicherbelegung des Amiga 



Der ganze Speicher ist in zwei Bereiche unterteilt. Die ersten 512 
KByte sind Chip-RAM, d.h. sie können auch von den Custom- 
Chips angesprochen werden. Der zweite Bereich besteht aus 
Fast-RAM oder ROM und kann nur vom 68000er verwaltet 
werden. 
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Die Dynamik liegt darin, daß die 8 MByte Fast-RAM bei der 
Grundversion noch nicht existieren und dynamisch ergänzt wer¬ 
den können. 

Wenn wir nun unserem Programm vom System einen Speicher¬ 
bereich Zuteilen lassen wollen, dann müssen wir angeben, ob es 
Chip- oder Fast-RAM sein soll. Geben wir nichts an, so wird 
zuerst versucht, Fast-RAM zu bekommen, und erst wenn dies 
nicht gelingt, wird Chip-RAM belegt. Dies liegt an der "Kost¬ 
barkeit" des Chip-RAM. 

Hinweis: Hierin liegt auch das Problem begraben, daß alte 

Programme bei Speicher-Erweiterungen abstürzen. 
Diese geben nämlich nicht genau an, welchen 
Speicherbereich sie brauchen, denn ohne Erweiterung 
liegt ja nur Chip-RAM vor. Dieses kann auch von 
den Custom-Chips angesprochen werden. Bei einer 
Speicher-Erweiterung wird aber Fast-RAM zugeteilt. 
Bei einem Zugriff der Chips auf diesen Bereich 
stürzt das System ab! 


3.11.2 Erste Gehversuche mit AllocMemO 

Für die ersten Versuche, Speicher zu belegen, greifen wir auf 
eine Exec-Funktion zurück. Sie heißt AllocMemO und belegt 
einen Speicherbereich von angegebener Größe und Kriterium. 
Man übergibt also zwei Parameter und erhält als Ergebnis die 
Adresse des zugeteilten Speichers. Wurde kein Speicher in der 
Größe und den Eigenschaften gefunden, erhält man einen Null- 
Pointer = Fehler zurück. 

MemoryBlock = AllocMemtByteSize, Requireoients); 

DO -198 DO Dl 

Für die Angabe der Eigenschaften des Speicherbereichs stehen 
uns die oben angesprochenen Flags MEMF_FAST und 
MEMF_CHIP zur Auswahl. Hinzu kommt noch 
MEMF_PUBLIC, das verbietet, den Speicherbereich zu ver¬ 
schieben. Diese Option ist aber noch gar nicht vorgesehen. Wei¬ 
terhin können Sie mit MEMF_CLEAR gleich Anweisung geben. 
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daß der Speicherbereich gelöscht, d.h. mit Nullen gefüllt werden 
soll. Der kleinste Speicherbereich kann übrigens die Größe von 8 
Bytes nicht unterschreiten! 

Hier ein Programm, das versucht, vier Textpuffer zu reservieren: 


* * 

* Speicherverwaltung : AUocateHemory * 

* asssssssssssssssssssssssssssssssssss * 

* * 

* Autor: Datum: Kommentar: * 

* ...... ____ _ * 

* Ugb 16.10.1987 nur für Test- ♦ 

* zwecke * 

* * 


***************************************^ 


#inclucle <exec/types.h> 

#include <exec/meiiiory.h> 

#define MemoryType MEMF.CHIP | MEMF^CLEAR 


UBYTE *UndoBuffer, *FileBuffer, *DiskBuffer, 
♦Suff Buff er, ♦AUocMemO; 


mainO 

i 

UndoBuffer = AUocMem(512L, MemoryType); 
if (fUndoBuffer) 

C 

printf("Leider Probleme beim ündo-Puffer!\n**); 

FreeMemoryO; 

exit(FALSE); 

> 

FileBuffer = AllocMem(30L, MemoryType); 
if (IFileBuffer) 
i 

printf("Leider Probleme beim FileBuffer!\n"); 

FreeMemoryO; 

exit(FALSE); 

> 

DiskBuffer * AllocMem(512L, MemoryType); 
if (IDiskBuffer) 

< 

printf("Leider Probleme beim DiskBuffer!\n"); 
FreeMemoryO; 
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exit(FALSE); 

> 

SuffBuffer = AllocMemdOL, MemoryType); 
if (!SuffBuffer) 

C 

printf(“Leider Probleme beim SuffBuffer!\n‘*); 

FreeMemoryO; 

exit(FALSE); 

> 


printf("Speieher reserviert!\n"); 

FreeMemoryO; 

exit(TRUE); 

> 


FreeMemoryO 

C 

if (UndoBuffer) 
if (FileBuffer) 
if (DiskBuffer) 
if (SuffBuffer) 


FreeMem(UndoBuffer, 512L); 
FreeMem(FileBuffer, 30L); 
FreeMem(DiskBuffer, 512L); 
FreeMem(SuffBuffer, 10L); 


printf("Speicher wieder freigegeben!\n"); 
> 


Programm 3.10: Speicherbelegung AllocMem() 


Programmbeschreibung 

Wichtig für unsere Arbeit ist das Include-File <exec/memory.h>. 
Es enthält die Speichertypendefinition. Wir fassen auch gleich 
zwei zusammen und definieren so eine Bezeichnung. Dann 
benötigen wir die vier Pointer auf die Speicherbereiche. Auch 
die Funktion liefert solch einen Wert und wird deshalb mitdefi¬ 
niert. 

Im Hauptprogramm wird dann nach und nach versucht, jeden 
einzelnen Bereich zu erreichen. Klappt dies bei einem nicht, so 
wird zur Freigaberoutine verzweigt, und das Programm bricht 
ab. Diese Routine arbeitet ähnlich der bekannten Close_All()- 
Funktion. Jeder Pointer wird geprüft, ob er auf einen Speicher¬ 
block zeigt. Nur wenn er das tut, wird der Speicher wieder frei¬ 
gegeben. So vermeiden wir den Fehler, der auftritt, wenn ein 
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Speicher freigegeben wird, der gar nicht belegt war (Guru Me¬ 
ditation). 

Für das Freigeben nutzen wir eine weitere Exec-Funktion: 

FreeMemtMenioryblock, ByteSize); 

-210 AI DO 

Der Nachteil dieser Methode ist, daß wir bei der Freigabe jeden 
Speicherbereich einzeln freigeben müssen und auch die Größe 
bekannt sein muß. Das ist unnötiger Aufwand für den Pro¬ 
grammierer. Außerdem erhöht das die Programmzeilenzahl, denn 
es muß jedesmal wieder getestet werden. 


3.11.3 Verbesserung mit AllocEntryQ 

Natürlich ist das Problem bekannt, daß oft mehrere Speicherbe¬ 
reiche vielleicht unterschiedlicher Eigenschaften gebraucht wer¬ 
den. Die AllocMem()-Funktion ist dafür zwar verwendbar, doch 
nicht optimal. Hilfe bietet, wie so häufig auf dem Amiga, eine 
Struktur. Diese Struktur enthält alle Speicherbereiche mit ihren 
Eigenschaften. Übergeben wir dann den Zeiger auf AllocEntryO, 
so wird versucht, alle Speicherbereiche zu erreichen. 

Die Grundstruktur mit dem Namen MemList: 

struct MemList 
i 

0x00 00 struct Node ml^Node; 

OxOE 14 UWORD ml_NumEntries; 

0x10 16 struct MemEntry ml_ME[13; 

0x18 24 
>; 

Die altbekannte Node am Anfang wird wie immer zum Ver¬ 
knüpfen gebraucht. Mit ml_NumEntries geben wir an, wie viele 
Einträge die Speicherliste haben wird. Die zweite eingebundene 
Struktur MemEntry gibt nähere Informationen zum ersten 
Speicherblock. 
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struct MemEntry 

Union 

i 

ULONG meu_Reqs; 

APTR meu Addr; 

> 

0x00 me_Un; 

0x04 04 ULONG me^Length; 
0x08 08 
>; 


Definition: 
me_un me_Un 
me_Reqs me__Un.meu_Reqs 
me_Addr me_Un.meu_Addr 

Der Wert me_Un enthält zu Anfang die Definition der Eigen¬ 
schaften dieses Speicherblocks. Nach Zuweisung findet man hier 
die Startadresse. In me_Length ist die Länge des Speicherbe¬ 
reichs festgehalten. 

Aus diesen beiden Strukturen, MemList und MemEntry, müssen 
wir uns noch eine eigene Struktur zusammensetzen, bevor wir 
AllocEntryO benutzen können. Dies sieht für unsere Aufgabe so 
aus: 


struct Speicherbedarf 
i 

struct MemList Kopf; 
struct MemEntry UndoBuffer; 
struct MemEntry FileBuffer; 
struct MemEntry DiskBuffer; 
struct MemEntry SuffBuffer; 

> Speicher; 

Struktur 3.35: Speicherbedarf 

Diese selbstgeschusterte Struktur wird einfach mit den ge¬ 
wünschten Werten gefüllt. Dann kann AllocEntryO auf gerufen 
werden. Es wird versucht, den Speicher zu bekommen, und in 
den einzelnen MemEntry-Strukturen finden wir die Daten. 

MemList = AUocEntry(Entry); 

DO -222 AO 

FreeEntry(Entry); 

-228 AO 



502 


Das große C-Buch zum Amiga 


Zum Abschluß hier das komplette Listing; 


y************************************** 

* * 

* Speicherverualtung : MemoryEntries * 

* ==s=sssss====ssss==ssssss=s=ss=sss * 

* * 

* Autor: Datum: Kommentar: * 

* _ _ _ ★ 

* Ugb 16.10.1987 nur für Test- * 

* zwecke * 

* * 

**************************************^ 


#include <exec/types.h> 

#include <exec/mefnory.h> 

#define MemoryType HEMF.FAST | MEMF.CLEAR 


struct HemList *SpeicherPtr, *AllocEntry(); 
APTR UndoData, FileOata, DiskData, SuffData; 

struct Speicherbedarf 

< 

struct MemList Kopf; 
struct MemEntry UndoBuffer; 
struct MemEntry FileBuffer; 
struct MemEntry DiskBuffer; 
struct MemEntry SuffBuffer; 

> Speicher; 


mainO 

C 

Speicher.Kopf.ml_NumEntries = 5; 

Speieher.Kopf.ml_meC0] .me_Length = 0; 

Speieher.UndoBuffer.me_Reqs = MemoryType; 

Spei eher.UndoBuffer.me_Length « 512L; 

Speicher.FileBuffer.me^Reqs * MemoryType; 

Speicher.FileBuffer.me^Length = 30L; 

Speieher.DiskBuffer.me_Reqs « MemoryType; 

Speicher.DiskBuffer.me_Length « 512L; 

Speieher.SuffBuffer.me”Reqs » MemoryType; 

Speieher.SuffBuffer.me_Length » 10L; 

SpeicherPtr > (struct MemList *)AUocEntry(&Speicher); 

if ((ULONG)SpeicherPtr & (1«31)) 
i 

printfC'Die Liste konnte nicht aufgestellt werdenl\n”); 
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exit(FALSE); 

> 

eise 

i 

UndoData = SpeicherPtr->ml_meCl] .me__Acldr; 
FileData = SpeicherPtr->ml_me[2].me_Addr; 
DiskData = SpeicherPtr->ml_meC31.me_Addr; 
SuffData = SpeicherPtr->ml ine[4].me^Addr; 

> 

pr 1 ntf("Speieher gesichert!\n"); 

F reeEnt ry(SpeicherPt r); 

printf("Speicher wird wieder freigegeben!\n"); 
exit(TRUE); 

> 


Programm 3.11: Speicherbelegung AUocEntryQ 


3.11.4 Die beste Lösung 

Die beiden vorgestellten Funktionen sind aus der Exec-Library. 
Wir befinden uns hier aber im Intuition-Kapitel, und deswegen 
finden Sie hier auch eine von Intuition unterstützte Speicherver¬ 
waltung. Diese ist mehr auf die Bedürfnisse eines Intuition-Pro¬ 
grammierers zurechtgeschnitten und wird sich für unsere Pro¬ 
blemstellung auch als die beste erweisen. 

Die beiden Funktionen heißen AllocRemember() und Free- 
Remember(). Wie der Name schon sagt, hilft uns Intuition beim 
Merken von reservierten Bereichen. Wir übergeben der Funktion 
einfach die Größe des gewünschten Speicherbereichs, den 
Speichertyp und den Zeiger auf eine Remember-Struktur. Zu¬ 
rück bekommen wir entweder eine Fehlermeldung, die durch 
NULL gekennzeichnet wird, oder die Adresse unseres Speicher¬ 
bereichs. Die Remember-Struktur wird von Intuition zur Ver¬ 
waltung benutzt und erinnert an die bisher belegten Speicherbe¬ 
reiche. Nun kommt aber der Clou: Wenn wir die Speicherberei¬ 
che freigeben wollen, dann müssen wir FreeRemember() nur den 
Zeiger auf die Remember-Struktur übergeben, und alle bisher 
reservierten Blöcke werden wieder freigegeben. 
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Zuerst die beiden Funktionen mit ihrem allgemeinen Format: 

MemBlock s AUocRemembertRementerKey, Size, Flags); 

DO -396 AO DO D1 

FreeRemembertReinetnberKey, ReallyForget); 

-408 AO DO 

Die Remember-Struktur sieht wie folgt aus: 

struct Reineinber 
{ 

0x00 00 struct Refflember *NextReineinber; 

0x04 04 ULONG RememberSize; 

0x08 08 UBYTE «Heoiory; 

OxOC 12 
>; 


Strukturbeschreibung 

Die Struktur ist eigentlich sehr simpel aufgebaut (aber wir¬ 
kungsvoll). Zu Anfang steht ein Zeiger auf eine weitere Re¬ 
member-Struktur. So werden mehrere Speicherblöcke in einer 
Liste verbunden. Über RememberSize erfährt man die Größe des 
Speicherbereichs, *Memory stellt die Adresse dar. 

Der Trick liegt nun darin, daß man sich zuerst nur einen Zeiger 
auf eine noch nicht vorhandene Remember-Struktur besorgt, der 
sog. RememberKey, und diesen auf NULL setzt. Übergeben wir 
diesen Zeiger an AllocRemember(), dann wird sofort die erste 
Remember-Struktur angelegt. Bei jedem weiteren Aufruf mit 
dem gleichen RememberKey wird dann die Remember-Liste 
verlängert. 

Die Arbeit für FreeRemember() ist zum Schluß ganz einfach. 
Die Funktion geht nach und nach die Liste durch und gibt jeden 
Bereich frei. Auch der Speicher, den die Liste selbst einnimmt, 
kann auf Wunsch des Programmierers freigegeben werden. 

Sie sehen: Der Vorteil liegt eindeutig in der einfachen Freigabe 
alle unterschiedlichen Speicherbereiche und in der Organisation, 
die von Intuition vorgenommen wird. Hier ist das Programm: 
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y************************************** 
* * 

* Spei eher Verwaltung : Remember * 


* * 

* Autor: Datum: Kommentar: * 

* _ _ _ * 

* Wgb 16.10.1987 nur für Test- * 

* zwecke ♦ 

* * 


**************************************y 


#include <exec/types.h> 

#include <exec/memory.h> 

# 1 nclude <intuition/intuition.h> 

#clefine MemoryType MEMF^CMIP | MEMF^CLEAR 


struct IntuitionBase *IntuitionBase; 
struct Remember *RememberPtr = NULL; 

VOID *OpenLibrary(); 

UBYTE *UndoBuffer, *FileBuffer, ’^DiskBuffer, 

♦SuffBuffer, *AUocRemember(); 


mainO 

C 

if (I(IntuitionBase - (struct IntuitionBase *) 

OpenLibrary(”intui tion. l ibrary**, OL))) 
i 

printf("Keine Intuition Library gefunden!\n”); 
exit(FALSE); 

> 

UndoBuffer = AUocRemember(&RememberPtr, 512L, MemoryType); 
FileBuffer = AllocReiiiember(&RememberPtr, 30L, MemoryType); 
DiskBuffer = AUocRemember(&RememberPtr, 512L, MemoryType); 
SuffBuffer = AUocRefnember(&RememberPtr, 10L, MemoryType); 

printf("Speieher reserviert!\n"); 

FreeRemember(RememberPtr, TRUE); 

printf("Speieher wieder freigegebeni\n"); 

CloseLibrary(IntuitionBase); 

> 


Programm 3.12: Speicherbelegung AUocRememberQ 
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4. Betriebssystemprogrammierung 


Im folgenden wollen wir Ihnen anhand eines längeren Pro¬ 
gramms das Zusammenspiel der verschiedenen Komponenten des 
Betriebssystems zeigen. Als Programm haben wir einen Textedi¬ 
tor gewählt, da dieser auf relativ viele Funktionen des Betriebs¬ 
systems zugreift: Man denke nur an die Speicherverwaltung, die 
Ausgabe des Textes im Fenster und an Eingaben über die Ta¬ 
statur. Außerdem können Sie diesen Editor zum Erstellen Ihrer 
C-Programme benutzen, sobald wir ihn fertiggestellt haben. Da¬ 
mit für Abwechslung gesorgt ist, werden wir Ihnen zwischen¬ 
durch ein paar Tips und Tricks zeigen, z.B. wie man mit dem 
Debugger auf Fehlersuche geht oder wie man Assembler-Pro¬ 
gramme einbindet. 

Zusätzlich zu den normalen Fähigkeiten, die jeder Editor besitzt, 
soll unser Editor noch ein paar kleine Extras für die Erstellung 
von Programmtexten enthalten. Damit sind nicht nur C-Pro¬ 
gramme gemeint, vielmehr sollte der Editor flexibel sein und 
sich an verschiedene Programmiersprachen anpassen lassen. 

Geschrieben wird der Editor mit dem Aztec-C-Compiler. Besit¬ 
zer anderer Compiler brauchen deswegen nicht zu verzweifeln. 
Das Programm ist so gehalten, daß es mit jedem Compiler 
übersetzt werden können sollte. Wenn wir auf speziellere Funk¬ 
tionen des Compilers oder seiner Hilfsprogramme (z.B.: Make) 
eingehen, so werden wir diese soweit beschreiben, daß die Be¬ 
sitzer anderer Compiler diese sinngemäß verwenden können. 
Dies ist besser, als jedesmal im Text einen Abschnitt für Aztec- 
C-Besitzer und einen für Lattice-Besitzer (und einen für ???) zu 
schreiben. In diesem Sinne: Viel Spaß! 


4.1 Planung des Editors 

Wenn man ein neues Programm anfängt, sollte man sich zuerst 
einmal hinsetzen und aufschreiben, was einem zu diesem Pro¬ 
gramm alles einfällt. Dies hilft, Denkfehler vorzeitig zu erken- 
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nen und große Änderungen im Programm zu vermeiden. Dabei 
sollte man nicht nur die Funktionen aufschreiben, sondern auch 
die Ideen, die man zur Realisation von Einzelproblemen hat. 
Diese kann man später bei der Programmierung verwenden. Be¬ 
ginnen wollen wir dieses Brainstorming damit, daß wir die 
grundlegenden Forderungen aufstellen, die unser Editor erfüllen 
soll: schnell, flexibel, programmierbar und komfortabel. 

Beginnen wir mit der ersten Forderung: Schnell soll er sein, un¬ 
ser Editor. Zum Problem der Geschwindigkeit gehört die Art 
und Weise, wie der Editor den Text im Speicher ablegt. Je bes¬ 
ser dieses organisiert ist, um so schneller kann der Text manipu¬ 
liert werden. Wir könnten beispielsweise einen Editorspeicher 
mit frei wählbarer Größe anlegen und den Text einfach als zu¬ 
sammenhängenden Block darin ablegen. Dies hätte den Vorteil, 
daß wir nur wenig Verwaltungsaufwand treiben müßten und 
somit sparsam mit dem Speicher umgingen. Auch ginge das La¬ 
den und Abspeichern des Textes in kürzester Zeit vonstatten, da 
wir den gesamten Text in einem Rutsch abspeichern bzw. laden 
könnten. 

Schwierig wird es dagegen beim Einfügen von Zeichen in den 
Text. Wenn wir für jedes Zeichen den gesamten nachfolgenden 
Text im Speicher um ein Zeichen nach hinten schieben wollten, 
so würde der Editor bereits bei kurzen Texten unerträglich 
langsam, da stets ein relativ großer Speicherbereich verschoben 
werden müßte. Günstiger ist es, wenn man die Zeile, in der 
Eingaben vorgenommen werden, in einen Puffer kopiert und 
dort die Zeichen einfügt. Da dieser Puffer nur eine geringe 
Größe hat, geht das Verschieben entsprechend schneller von¬ 
statten. Der Puffer wird erst dann in den Text zurückkopiert, 
wenn der Benutzer die Zeile mit dem Cursor wieder verläßt. 

Dieses Verfahren eignet sich recht gut, wenn Sie Speicherplatz 
sparen und nicht zu große Texte bearbeiten wollen. Aber auch 
hier ist irgendwo eine Grenze: Je nachdem, wie schnell der com- 
pilierte Code arbeitet, der den Text verschiebt, können recht 
lange Wartezeiten entstehen; besonders dann, wenn der Text 
größer als 30 KByte wird. Noch ein Nachteil fällt vor allem 
beim Scrollen auf: Um von einer Zeile in die nächste zu kom- 
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men, müssen wir stets die gesamte Zeile nach dem Zeilenende 
durchsuchen, und das dauert etwas länger, als wenn wir den 
Anfang der nächsten Zeile einfach berechnen könnten. 

Eine andere Möglichkeit, den Text im Speicher abzulegen, be¬ 
steht in der Verwendung eines Arrays. Dazu legen wir die ma¬ 
ximale Anzahl von Zeichen pro Zeile und die maximale Zeilen- 
anzahl fest und definieren ein Array mit den entsprechenden 
Dimensionen: zeilenfeld[MaxZeile][MaxSpalte]. Dadurch haben 
wir einen sehr schnellen Zugriff auf jede einzelne Zeile und je¬ 
des einzelnen Zeichen innerhalb einer Zeile. Auch das Einfügen 
von Zeichen innerhalb einer Zeile könnte direkt im Text vorge¬ 
nommen werden und wäre schnell genug, da wir nur die Zei¬ 
chen dieser einen Zeile verschieben müßten. Allerdings hat diese 
Methode auch Nachteile: 

Wenn wir neue Zeilen einfügen wollen, so müssen wir 
wieder den gesamten Text verschieben. 

Die Größe des Arrays ist festgelegt. Wenn wir einen 
größeren Text bearbeiten wollen, so müssen wir zuerst die 
Größe des Arrays ändern, wobei dessen Inhalt gelöscht 
wird. 

Nicht alle Zeilen nutzen die maximale Zeilenlänge wirklich 
aus. Die Praxis hat gezeigt, daß stets nur wenige Zeilen 
wirklich lang sind, während die meisten etwa ein Drittel 
bis die Hälfte der möglichen Zeilenbreite ausnutzen. 

Aufgrund dieser Nachteile werden wir eine andere Methode 
wählen und die Zeilen als verkettete Liste ablegen. Dann ist die 
maximale Anzahl von Zeilen nur durch den vorhandenen Spei¬ 
cher begrenzt, und wir kommen schnell von einer Zeile in die 
nächste, indem wir uns den Zeiger auf die nächste Zeile holen. 
Die Zeilen haben keine feste Länge, so daß kurze Zeilen auch 
nur wenig Speicher beanspruchen. Dies hat zwar zur Folge, daß 
die Speicherverwaltung verkompliziert wird, wie Sie später noch 
sehen werden, aber dafür haben wir einen guten Kompromiß 
zwischen Geschwindigkeit und geringem Platzbedarf. 

Nachdem wir wissen, wie unsere Zeilen aussehen, müssen wir 
uns überlegen, wo wir den Speicher für jede einzelne Zeile her- 
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nehmen. Prinzipiell könnten wir den Speicher jedesmal vom Be¬ 
triebssystem anfordern. Dies würde allerdings dazu führen, daß 
der Speicher zerstückelt würde, da das Betriebssystem nicht 
darauf ausgelegt ist, eine große Anzahl kleiner Speicherbereiche 
zu vergeben. Besser ist es, wenn wir jeweils einen Block fester 
Größe (z.B. 5 KByte) vom Betriebssystem anfordern und diesen 
nach Bedarf selbst zerteilen. Die entsprechenden Funktionen 
schreiben wir so, daß wir uns später, wenn wir im Programm 
eine neue Zeile anfordern wollen, keine Gedanken mehr über 
das "wie" zu machen brauchen. Lassen wir es bei diesem groben 
Modell bewenden. Ins £>etail gehen wir erst, wenn es ernst wird, 
wir also die Speicherverwaltung implementieren wollen. 

Jetzt ein paar Ideen, die uns zum Thema Komfort eingefallen 
sind: Man sollte die Änderungen, die man in einer Zeile gemacht 
hat, durch eine Undo-Funktion wieder rückgängig machen kön¬ 
nen. Da wir die Zeilen zum Editieren ja ohnehin in einen Puffer 
kopieren müssen, läßt sich die Undo-Funktion einfach dadurch 
realisieren, daß man die Pufferzeile löscht und wieder den alten 
Inhalt, der sich ja noch im Speicher befindet, sichtbar macht. 

Etwas, was uns beim Arbeiten mit Editoren und Textverarbei¬ 
tungen immer sehr gestört hat, auch wenn es nur eine Kleinig¬ 
keit war, ist, daß sich diese nur selten merken konnten, ob der 
Text verändert wurde. Beim Verlassen des Editors bekam man 
auf jeden Fall die Frage "Sind Sie sicher, daß Sie den Text schon 
abgespeichert haben?" auf dem Monitor angezeigt. Besser ist dies 
bei Ed gelöst, der nur dann diese Frage stellt, wenn man den 
Text wirklich verändert hat. Um aber festzustellen, ob der Text 
verändert wurde, muß bei jeder Veränderung ein Flag gesetzt 
werden. Dies ist auch der Grund, warum wir dieses Thema hier 
schon zur Sprache bringen. Vergessen wir nämlich später auch 
nur an einer einzigen Stelle das Setzen dieses Flags, so funktio¬ 
niert die ganze Sache nicht, und wir müssen uns auf die mühe¬ 
volle Suche nach dem Fehler machen. 

Ebenfalls von Anfang an im Auge zu behalten ist, daß wir spä¬ 
ter mehrere Fenster gleichzeitig mit dem Editor bearbeiten kön¬ 
nen wollen. Dies ist vor allem dann von großem Nutzen, wenn 
man Textstücke zwischen verschiedenen Texten austauschen will. 
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Haben Sie nur ein Fenster, so ergibt dies ein lästiges Laden und 
Abspeichern. Aber wir können nicht so einfach mehrere Fenster 
öffnen. Jedes Fenster braucht seinen eigenen Editorspeicher, sei¬ 
nen eigenen Cursor und evtl, noch weitere Dinge. Dies bedeutet, 
das wir alle wichtigen Informationen Ober den Text wie Anzahl 
der Zeilen, Cursor-Position etc. nicht global abspeichern dürfen, 
sondern in einer Struktur, von der es dann für jedes Editorfen¬ 
ster genau eine gibt. Ferner gibt es dann noch einen Zeiger auf 
die aktuelle Struktur, deren Fenster gerade aktiv ist. Dies alles 
bedeutet zwar am Anfang mehr Arbeit für uns, aber die Imple¬ 
mentation mehrerer Fenster wird dafür hinterher um so einfa¬ 
cher. 

Eine interessante Fähigkeit des Amiga ist die Möglichkeit, jede 
Taste mit einer beliebigen Zeichenkette zu versehen. So können 
Sie Z.B. einstellen, daß der Amiga jedesmal, wenn Sie Alt + "Ä" 
drücken, ein "ae" sendet oder "\344" (Oktal-Code von "ä"). Oder 
Sie können sich aussuchen, ob die Return-Taste ein Linefeed 
(LF), ein Return (CR) oder ein CRLF sendet. Oder Sie können 
^nderzeichen auf beliebige Tasten legen, an die Sie sonst nicht 
herankommen. Die Möglichkeiten, die Ihnen hierdurch gegeben 
werden, lassen sich wahrscheinlich erst im praktischen Einsatz 
überblicken. 

Auch sollte unser Editor mit echten Tabulatoren arbeiten können 
und nicht einfach nur Blanks einfügen. Wenn Sie Ihre Pro¬ 
gramme schön strukturieren (einrücken) wollen, so müssen Sie 
beim Arbeiten mit Ed viele Blanks einfügen, die auch viel 
Speicher kosten. Wenn Sie einen Aztec-C-Compiler besitzen, so 
können Sie natürlich dessen Editor Z benutzen, der echte Tabu¬ 
latoren einfügt. Allerdings ist die Bedienung von Z nichts für 
sanfte Gemüter, denn es bedarf schon einer gehörigen Einge¬ 
wöhnungszeit, bis man damit umgehen kann. Am besten wäre es 
natürlich, wenn man die Tabulatoren beliebig setzen könnte, also 
nicht nur jede dritte (vierte, fünfte...) Spalte, sondern einen in 
Spalte 3, einen in Spalte 10 und einen in Spalte 20. Dies ist zwar 
aufwendiger zu programmieren, macht den Editor aber flexibler. 

Auto-Indent hängt ebenfalls, wenn auch nicht direkt, mit Ta¬ 
bulatoren zusammen. Darunter versteht man, daß der Editor, 
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wenn Sie am Ende einer Zeile Return drücken, nicht in die erste 
Spalte der nächsten Zeile geht, sondern in die Spalte, in der 
auch in der darüberliegenden Zeile der erste Buchstabe steht 
(bzw. das erste Zeichen, das weder Blank noch Tabulator ist). 
Wenn Sie Ihre Programme ordentlich strukturieren, so sparen Sie 
sich mit Auto-Indent jede neue Zeile auch neu einrücken zu 
müssen. 

Der Editor sollte auch Sonderzeichen anzeigen und nicht einfach 
wie Ed "file contains binary" melden und abbrechen. Mit Son¬ 
derzeichen sind insbesondere die Zeichen mit den ASCII-Codes 
unterhalb von Space gemeint. Da diese Zeichen nicht im Zei¬ 
chensatz des Amiga vorhanden sind, könnte man diese in einer 
anderen Farbe ausgeben, wobei man auf den ASCII-Code des 
Zeichens einen konstanten Wert (z.B. 64) addiert, so daß man 
wieder ein ausgebbares Zeichen erhält. So würde das Zeichen 
mit dem ASCII-Code Eins beispielsweise als rotes A im Text 
erscheinen (Code(A) = 65 = 1 + 64). Ferner könnte man bei der 
Ausgabe die reservierten C-Befehlswörter im Fettdruck ausgeben 
lassen. Dies würde die Programme noch übersichtlicher machen. 

Zum Thema Komfort ist uns schließlich noch das Folding ein¬ 
gefallen. Der Vorteil von Folding ist, daß man einzelne Pro¬ 
grammteile, die eine bestimmte Funktion zu erfüllen haben, 
einfach wegfalten (unsichtbar machen) kann. Dann sieht man 
nur noch einen Kommentar, aus dem die Funktion des entspre¬ 
chenden Programmteils hervorgeht. Um an den Text zu gelan¬ 
gen, der in der Falte steht, kann man entweder in die Falte ein- 
treten, so daß man dann nur noch die Falte sieht, oder diese 
auffalten. Die Programme werden dadurch übersichtlicher und 
besser lesbar. 

Wenden wir uns nun der Programmierbarkeit unseres Editors zu. 
Alle Funktionen des Editors sollten sich über einfache Kom¬ 
mandos auf rufen lassen. Aus diesen Kommandos lassen sich 
Kommandofolgen bilden, indem man die einzelnen Kommandos 
durch ein Semikolon trennt. Ferner sollten sich Kommandofol¬ 
gen klammern lassen und einzelne Kommandos oder geklam¬ 
merte Kommandofolgen mehrfach ausführen lassen, indem man 
eine Zahl direkt davor schreibt. Kommt Ihnen bis jetzt alles 
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recht bekannt vor, hmm? Richtig, soviel kann Ed auch, doch 
wir wollen noch ein paar Schritte weitergehen. 

Zuerst erlauben wir die Verwendung von Variablen, und zwar 
von Variablen, die Zahlen (Cursor-X/Y-Position o.ä.), Strings 
oder Kommandofolgen enthalten. Schreiben wir eine Zahl-Va¬ 
riable vor ein Kommando, so wird dieses sooft ausgeführt, wie 
der Inhalt der Variablen angibt. Außerdem erlauben wir erwei¬ 
terte Kontrollstrukturen, also For-To-Do-Schleifen, While-Do- 
Schleifen, und If-Then-Else. Selbstverständlich können wir die 
Funktionstasten beliebig mit solchen Kommandofolgen belegen. 
Weitere Ideen werden uns bei den einzelnen Befehlen noch ein¬ 
fallen, z.B. die Möglichkeit, beim Suchen und Ersetzen einen 
Bereich (von Zeile bis Zeile) anzugeben, in dem gesucht werden 
soll. 

Ebenfalls nicht schlecht wäre es, wenn wir CLI-Befehle direkt 
vom Editor aus auf rufen könnten. E>ann bräuchten wir den 
Editor nämlich gar nicht mehr zu verlassen, um z.B. auf einen 
Tastendruck unseren Text abzuspeichern und den Compiler 
aufzurufen. 


Nachdem wir nun bereits eine ganze Menge an Ideen zusammen¬ 
getragen haben, die wir im Zuge dieses Buches gar nicht alle 
realisieren können, müssen wir uns noch Gedanken über die 
Datenstrukturen machen, auf denen unser Editor aufbaut. Die 
Datenstrukturen gehören zu den wichtigsten Dingen, über die 
man sich vor der Programmierung Gedanken machen muß. So ist 
es z.B. ein besonderes Merkmal des Amiga, daß alle Daten¬ 
strukturen, auf die das Betriebssystem zugreift, ähnlich aufge¬ 
baut sind; man denke nur an die Listen. Dies erleichtert die Ma¬ 
nipulation dieser Objekte. Die erste Datenstruktur unseres Edi¬ 
tors ist die Zeile: 


struct Zeile 
{ 

struct Zeile *succ; 
struct Zeile *pred; 
UBYTE flags; 

UBYTE len; 

/* UBYTE Zeilet] */ 


Zeiger auf nächste Zeile 
Zeiger auf vorige Zeile 
Diverse Flags 
Länge der Zeile 
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Mit den ersten beiden Zeigern wird später die verkettete Liste 
aufgebaut. Zwei Zeiger brauchen wir deswegen, weil wir ja 
nicht nur von einer Zeile in die nächste, sondern auch in die 
vorige kommen wollen. Außerdem stellt uns der Amiga Funktio¬ 
nen für doppelt verkettete Listen zur Verfügung, die wir auch 
für unsere Zeilen verwenden können. Ist (flags & 128) ungleich 
null, so befindet sich die Zeile gerade im Puffer, weil der Be¬ 
nutzer diese zu ändern gedenkt. Dieses Flag werden wir bei der 
Ausgabe brauchen, da wir den Puffer ausgeben müssen, wenn 
wir auf eine Zeile stoßen, bei der dieses Flag gesetzt ist. Weitere 
Flags werden wir nach Bedarf definieren. 

Die Bedeutung von len dürfte dagegen klar sein. Es gibt die ge¬ 
samte Länge der Zeile an, also inklusive CR, LF oder CRLF, 
die ja das Zeilenende signalisieren. Auf diese Art und Weise 
können wir auch Zeilen ohne ein Zeilenende zulassen, zum Bei¬ 
spiel dann, wenn eine Zeile länger werden soll, als der Bild¬ 
schirm breit ist. Anstatt diese Zeile nach rechts aus dem Bild¬ 
schirm heraus fortzusetzen, könnten wir sie am rechten Bild¬ 
schirmrand trennen und daraus zwei Zeilen machen, wovon die 
erste nicht durch ein CR, LF oder CRLF beendet wird. Auf 
diese Art und Weise werden übrigens bei Textverarbeitungen 
Absätze behandelt. 

Die Zeile selbst folgt direkt hinter len. Da ihre Länge nicht fest¬ 
gelegt ist, können wir sie auch nicht in der Struktur aufführen. 
Die Länge der Struktur einschließlich Zeile ergibt sich zu: 

Gesamtlänge = (sizeof(struct Zeile) Zeile.len 1) & -2. 

Die Gesamtlänge muß geradzahlig sein, da beim Amiga Zeiger 
(oder generell: Wörter und Langwörter) an geraden Adressen im 
Speicher liegen müssen. Dies setzt die CPU MC68000 voraus, 
andernfalls erhalten Sie eine Guru-Meditation mit der Fehler¬ 
nummer 00000003. 

Die nächste Struktur gehört zu den Speicherblöcken, in denen 
die Zeilen liegen. Die Speicherblöcke sind ebenfalls über eine 
verkettete Liste miteinander verbunden. Ferner benötigen wir 
einen Zeiger auf eine Liste aller freien Speicherstücke, die in 
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diesem Block liegen, die Länge des Blocks und die Anzahl der 
unbenutzten Bytes. £>as Ganze sieht also wie folgt aus: 

struct Speicherblock 
< 

struct Speicherblock *succ; 

struct Speicherblock *pred; 

ULONG lsenge; 

ULONG frei; 

struct FList Freiliste; 

> 

Die ersten beiden Variablen dienen wieder dem Einfügen des 
Speicherblocks in eine doppelt verkettete Liste. Die Größe des 
Blocks ohne die Speicherblock-Struktur gibt laenge an. Dies ent¬ 
spricht der Anzahl der freien Bytes, die in einem unbenutzen 
Block vorhanden sind, abzüglich der Länge einer Spei- 
cherstueck-Struktur, die nachfolgend beschrieben wird. Frei da¬ 
gegen gibt an, wie viele Bytes in diesem Block tatsächlich noch 
frei sind. Jetzt tritt das Problem auf, wo diese freien Bytes lie¬ 
gen. Klar ist, daß diese nicht unbedingt hintereinander im 
Speicher liegen, sondern an beliebigen Stellen. Wenn nämlich 
eine Zeile gelöscht wird, so entsteht ein freies Stück Speicher, 
das nicht zwingend an einem anderem Stück freien Speicher lie¬ 
gen muß. Da jede Zeile mindestens 10 Bytes lang ist (sizeof( 
struct Zeile)!), haben wir 10 Bytes zum Auf bauen einer Liste 
aller freien Speicherstücke eines Blocks zur Verfügung. Jedes 
Element dieser Liste hat folgenden Aufbau: 

struct Speicherstueck 
< 

struct Speicherstueck *succ; 

struct Speicherstueck *pred; 

UWORD len; 

> 

Die ersten beiden Elemente wurden mit Rücksicht auf die Listen 
des Betriebssystems gewählt. Dabei handelt es sich auch um 
doppelt verkettete Listen, für deren Verwaltung eine Reihe von 
Funktionen in der Exec-Library bestehen. Dadurch, daß wir 
dieselbe Verkettung benutzen, können wir diese Funktionen 
auch für unsere Listen verwenden und müssen keine eigenen 
schreiben. Das Element len enthält diesmal die Länge des ge¬ 
samten Speicherstücks, also einschließlich der Speicherstueck- 


Nächster Speicherblock 
Voriger Speicherblock 
Maximale Anzahl der freien Bytes 
Momentane Anzahl der freien Bytes 
Liste der unbelegten Stücke 
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Struktur. Was noch fehlt, ist die FList-Struktur, die denselben 
Aufbau hat wie der Listenkopf einer Liste des Betriebssystems: 

struct FList 
i 

struct Speicherstueck *head; 
struct Speicherstueck *tail; 
struct Speicherstueck *tailpred; 

> 

Die Struktur sollte Ihnen von den Exec-Lists bekannt sein, so 
daß wir diese hier nicht noch einmal erklären wollen (siehe An¬ 
hang: Exec-Library). Es sei nur soviel gesagt, daß head auf das 
erste und tailpred auf das letzte Element der Liste zeigen, wäh¬ 
rend tail immer Null ist. Diese Vereinbarung vereinfacht das 
Einfügen und Löschen in Listen. 

Ziemlicher Aufwand für die Verwaltung der Zeilen, meinen Sie? 
Tja, da haben Sie nicht ganz unrecht. Wir könnten doch den 
Speicher für jede Zeile einfach vom Betriebssystem anfordern? 
Im Prinzip schon, aber ... Bedenken Sie, daß ein Text aus 1000 
und mehr Zeilen bestehen kann. Jedesmal, wenn Sie eine Zeile 
ändern, müssen Sie, wenn sich deren Länge ändert, den alten 
Speicher freigeben und neuen allokieren. Wenn Sie den Text ei¬ 
nige Zeit editiert haben, sieht Ihr Speicher aus wie ein Schwei¬ 
zer Käse: ein Loch neben dem anderen. 

Nun meinen Sie, daß es uns nicht anders ergehen würde, wenn 
wir das Problem selbst in die Hand nehmen? Das stimmt nicht 
ganz! Wenn wir eine neue Zeile anfordern, so werden wir zuerst 
nach einem Speicherstück suchen, das genau die gesuchte Länge 
hat. Finden wir ein solches nicht, so nehmen wir den Speicher 
von dem größten Speicherstück, das wir haben. Dadurch stellen 
wir sicher, daß wir kleine Speicherstücke nicht unnötig weiter 
verkleinern. Stellen Sie sich vor, wir brauchen 14 Bytes, und das 
nächstgrößere Speicherstück faßt 16 Bytes. Würden wir dieses 
auf teilen, so erhielten wir zwei Speicherstücke, wovon eines 14 
und das andere 2 Bytes groß wäre. Diese zwei Bytes würden al¬ 
lerdings nicht mehr dazu ausreichen, das Speicherstück wieder in 
die Liste aller freien Speicherstücke einzuhängen, da wir dazu 
mindestens 10 Bytes für die Speicherstueck-Struktur benötigten. 
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Erst wenn wir nicht mehr genug Platz zur Verfügung haben, al- 
lokieren wir einen neuen Speicherblock und fügen ihn in die 
Blockliste ein. 

Was uns zur vorerst letzten Struktur bringt. Die Struktur, ohne 
die nichts läuft, ist die Editor-Struktur, von der für jedes Edi¬ 
torfenster eine existiert und die alle wichtigen Daten auf nimmt: 

struct Editor 
i 

struct Editor *succ; 
struct Editor *pred; 
struct Window *uindow; 
struct BList block; 
struct ZList Zeilen; 

UBYTE pufferCMAXBREITE]; 

UBYTE tabstringCHAXBREITE]; 

UUORD anz_zeilen; 
struct Zeile *aktuell; 
struct Zeile *top; 

UWORD toppos; 

UWORD xpoSfVpos; 

UUORD changed:1; 

UWORD insert:1; 

> 

Dazu gehören noch zwei weitere Strukturen, die aber einfach 
nur Listenköpfe darstellen: 

struct BList 
i 

struct Speicherblock *head; 
struct Speicherblock *tail; 
struct Speicherblock *tailpred; 

> 

struct ZList 
i 

struct Zeile *head; 
struct Zeile *tail; 
struct Zeile *tailpred; 

> 

Die einzelnen Elemente der Editor-Struktur dürften Ihnen ei¬ 
gentlich keine Probleme bereiten, und falls doch, so werden 
diese spätestens beim Programmieren gelöst. Allerdings sei schon 
jetzt gesagt, daß die Editor-Struktur noch um einige Elemente 


Zeiger auf das Editorfenster 

Liste der Speicherblocke 

Liste der Zeilen 

Puffer zum Editieren 

Tabulatoren 

Anzahl der Zeilen 

Zeiger auf aktuelle Zeile 

Zeiger auf oberste Zeile, 

die im Bildschirm sichtbar ist. 

Nummer der obersten Zeile 

Cursor-Position 

Ist 1, falls Text verändert 

Ist 1, falls Einfügemodus 
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erweitert werden wird, da sich bei der Programmierung zeigen 
wird, daß noch die eine oder die andere Variable nützlich für 
den Editor wäre, an die wir in diesem frühen Stadium noch 
nicht gedacht haben. 


4.2 Ein Programmgerüst 

Beginnen wollen wir die Programmierung mit einem Gerüst, in 
das wir dann unseren Editor einbauen werden. Das folgende 
Programm öffnet nur die Librarys, über die auf dem Amiga auf 
die Funktionen des Betriebssystems zugegriffen wird, und gibt 
eine Meldung aus, wenn dies erfolgreich geschehen ist. Beachten 
Sie bitte, daß Sie nur dann Funktionen einer Library auf rufen 
können, wenn Sie diese zuvor mit OpenLibrary geöffnet haben. 
Auch gehört es zum guten Ton, am Programmende alle geöffne¬ 
ten Librarys wieder zu schließen. 

«Editor.c> 


* 


* Includes: 

* 

************ ^ 


#inclucle <exec/types.h> 

#include <intuition/intuition.h> 


^*********** 

* 

* Defines: 

* 

•klfkitltltititftltit ^ 


#define REV 33L 


^**************Sr******* 

* 

* Externe Funktionen: 

* 

**********************! 


struct Library *OpenLibrary(); 
void CloseLibraryO; 
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* Globale Variablen: 

* 

********************* f 


struct Library *IntuitionBase = NULL, *GfxBase = NULL; 
struct Library *DosBase = NULL; 

^***************** 

* 

* Hauptprogramm: 

* 

*****************! 


mainO 

C 

if ( KlntuitionBase = OpenLibrary(”intuition.library**,REV))) 
goto Ende; 

if ( ((GfxBase = OpenLibrary(“graphics.library“,REV))) 
goto Ende; 

if ( KDosBase = OpenLibrary(“dos.library”,REV))) 
goto Ende; 

printf(“Alles geöffnet\n‘*); 

Ende: 

if (DosBase) CloseLibrary(DosBase); 
if (GfxBase) CloseLibrary(GfxBase); 
if (IntuitionBase) CloseLibrary(IntuitionBase); 

> 

Die #include-Befehle binden die Definitionen der Datenstruk¬ 
turen ein, auf die wir uns beziehen, wenn wir auf Betriebssy¬ 
stemroutinen zugreifen. Wenn wir diese Befehle wegließen, so 
würde der C-Compiler mehrere Fehlermeldungen wegen unbe¬ 
kannter Strukturen ausgeben. Auch sollten Sie alle Funktionen, 
die Sie innerhalb eines Programms verwenden, zuvor deklarie¬ 
ren, damit der C-Compiler Oberprüfen kann, ob Sie den Wert 
einer Funktion auch an eine Variable vom richtigen Typ Ober¬ 
geben. 

Beim Compilieren wird Ihnen die lange Zeit auffallen, die der 
Compiler braucht, um die Include-Dateien einzulesen. Weil dies 
anscheinend auch die Entwickler des Aztec-C-Compilers gestört 
hat, haben Sie eine Möglichkeit eingebaut, solche Include-Da- 
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teien zu präcompilieren. Diese präcompilierten Includes lassen 
sich erheblich schneller einbinden als die normalen Includes. Zu 
diesem Zweck schreiben Sie eine Datei, die nur die #include- 
Anweisungen Ihres Quelltextes enthält. In unserem Beispiel sähe 
die Datei also wie folgt aus: 

<Editor.prelist> 

#inclucie <exec/types-h> 

#include <intuition/intuition.h> 

Diese Datei wird nun compiliert, wobei Sie allerdings dem Com¬ 
piler mitteilen müssen, daß er eine Datei mit den präcompilier¬ 
ten Includes erzeugen soll. Dies geschieht beim Aztec mit der 
Option +H: 

cc ■►Hpre/editor.pre pre/editor.prelist 

Dabei sind wir davon ausgegangen, daß sich die Datei mit den 
Include-Anweisungen unter dem Namen "editor.prelist" im pre- 
Verzeichnis befindet. Erzeugt wird im selben Verzeichnis die 
Datei "editor.pre", die Sie mit der Option +I beim Compilieren 
des eigentlichen Programms einbinden können: 

cc ■•■Ipre/Editor.pre src/Editor.c 

Das Verzeichnis src (Source = Quelltext) soll dabei die Datei 
Editor.c beinhalten. Sie werden feststellen, daß der Compiler 
nun wesentlich schneller arbeitet. Eine weitere Möglichkeit zur 
Vereinfachung der Übersetzung besteht in der Verwendung von 
Make. Make kommt immer dann zum Einsatz, wenn ein Pro¬ 
gramm aus mehreren Modulen besteht, die erst beim Linken 
zusammengebunden werden. Bei größeren Programmen ist es 
sinnvoll, diese in kleinere Teilprogramme - Module - zu zerle¬ 
gen, die getrennt übersetzt und dann erst vom Linker zusam¬ 
mengebunden werden. Dadurch bleibt das Programm übersicht¬ 
lich, und bei Änderungen muß jeweils nur das geänderte Modul 
neu übersetzt werden und nicht das gesamte Programm. 

Make übernimmt das Compilieren und das Linken der Module, 
so daß Sie sich nicht mehr darum kümmern müssen. Sie sagen 
Make, aus welchen Modulen Ihr Programm besteht und wie 
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diese zu compilieren und zu linken sind. Wenn Sie Make aufru¬ 
fen, so überprüft es anhand des Datums und der Uhrzeit, ob Sie 
Teile Ihres Programms geändert haben, übersetzt ggf. diese Mo- 
dule neu und linkt alle Module zum fertigen Programm zusam¬ 
men. 

Damit Make dies tun kann, teilen Sie ihm in der Make-Datei 
(Make-File) mit, welche Dateien Ihres Programms von welchen 
anderen Dateien abhängen. So hängt z.B. die Objektdatei eines 
Moduls von dessen Quelltext ab, und das fertige Programm 
hängt von den Objektdateien aller Module ab. Aufgrund dieser 
Abhängigkeiten und aufgrund des Datums und der Uhrzeit, zu 
der diese Dateien erzeugt worden sind, bestimmt Make, ob wel¬ 
che geändert wurden und welche Schritte auszuführen sind, um 
das Programm neu zu erstellen. Es ist also wichtig, daß die 
Uhrzeit und das Datum in Ihrem Amiga stets richtig eingestellt 
sind. 

Um dies etwas anschaulicher zu machen, wollen wir nun Make 
verwenden, um unseren Editor übersetzen zu lassen. Dazu 
schreiben wir zunächst einmal auf, aus welchen Dateien unser 
Editor bisher besteht: 

Editor 

src/Editor.o 

src/Editor.c 

pre/Editor.pre 

pre/Editor.prelist 

Eigentlich gehören die Include-Dateien auch noch dazu, aber da 
wir diese nicht ändern werden und da diese in pre/Editor.pre 
schon enthalten sind, können wir auf sie verzichten. Wie hängen 
nun diese fünf Dateien voneinander ab? Das fertige Programm 
Editor hängt sicherlich von dem Objektmodul src/Editor.o ab, 
aus dem es gelinkt wird. Das dabei auch die Bibliotheken eine 
Rolle spielen, ist hier nicht von Belang, da wir diese nicht än¬ 
dern werden. Die Abhängigkeiten brauchen wir nur für die Da¬ 
teien aufzustellen, die wir im Laufe der Programmentwicklung 
zu ändern gedenken. 

Das Objektmodul src/Editor.o hängt seinerseits vom Quelltext 
src/Editor.c und von den präcompilierten Includes pre/Editor. 
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pre ab; diese wiederum von pre/Editor.prelist, die die Namen 
der Includes enthält, die präcompiliert werden sollen. Wenn wir 
für Make die Abhängigkeiten aufschreiben wollen, so schreiben 
wir den Dateinamen in die erste Spalte einer Zeile, gefolgt von 
einem Eloppelpunkt. Dahinter schreiben wir die Dateien, von 
denen diese Datei abhängt. Für unseren Editor sähe das Ganze 
wie folgt aus: 

Editor: src/Editor.o 

src/Editor.o: src/Editor.c pre/Editor.pre 

pre/Editor.pre: pre/Editor.prelist 

Die Dateien src/Editor.c und pre/Editor.prelist hängen von kei¬ 
nen anderen Dateien ab. Eiamit Make weiß, wie alle diese Da¬ 
teien zu compilieren bzw. zu linken sind, müssen wir noch ei¬ 
nige Anweisungen in die Make-Datei schreiben. Dabei schreiben 
wir diese jeweils direkt unter die Zeile, die die Abhängigkeit 
beschreibt. Die Befehle dürfen übrigens nicht in der ersten 
Spalte beginnen, da dies den Abhängigkeiten Vorbehalten ist. Sie 
sollten also mindestens ein Blank davor setzen. Sie können hinter 
jede Abhängigkeit beliebig viele Anweisungen setzen. Make 
führt diese solange aus, bis es wieder an eine Abhängigkeit oder 
an das Ende der Make-Datei gelangt. 

Stellen wir nun die Anweisungen zusammen, die unseren Editor 
erzeugen. Um aus dem Objektmodul das fertige Programm zu 
machen, muß folgender Befehl ausgeführt werden: 

ln src/Editor.o -Ic -o Editor 
Zum Übersetzen des Quelltextes: 

cc +Ipre/Editor.pre src/Editor.c 

Zum Erzeugen der präcompilierten Includes wollen wir zwei 
Anweisungen verwenden. Wenn Sie diese so erzeugen, wie wir es 
oben beschrieben haben, so erzeugt der C-Compiler eine Ob¬ 
jektdatei, obwohl dies gar nicht nötig wäre, da uns ja nur die 
precompilierten Includes interessieren. Auch wird der Assembler 
mit aufgerufen, was zusätzlich Zeit kostet. Wir werden daher das 
Aufrufen des Assemblers mit der Option -A unterbinden und 
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die Assembler-Datei, die der Compiler trotzdem erzeugt, auf die 
RAM-Disk schreiben lassen und anschließend löschen: 

cc ’A ■t'Hpre/Editor.pre pre/Editor.prelist *0 ram:Ed.asm 
delete ramiEd.asm 

Unsere Make-Datei zum Erzeugen des Editors sieht damit wie 
folgt aus: 

Editor: src/Editor.o 

ln src/Editor.o -Ic -o Editor 

src/Editor.o: src/Editor.c pre/Editor.pre 
cc «IpreEditor.pre src/Editor.c 

pre/Editor.pre: pre/Editor.prelist 

cc -A ■•■Hpre/Editor.pre pre/Editor.prelist -0 ram:Ed.asm 
delete raai:Ed.asin 

Make erzeugt nun die Datei, deren Namen sich zuerst in der 
Make-Datei findet. In unserem Fall also Editor. Wollen Sie eine 
andere Datei erzeugen lassen, z.B. src/Editor.o, so geben Sie de¬ 
ren Namen bereits beim Aufruf vom CLI aus an: 

make src/Editor.o 

Nun wollen wir es damit aber nicht bewenden lassen, sondern 
Make noch ein bißchen weiter ausnutzen. Da unser Programm 
später aus mehreren Modulen besteht, können wir die Make- 
Datei jetzt schon mal darauf vorbereiten. Als erstes wollen wir 
die Objektmodule, aus denen unser Editor besteht, in einer Va¬ 
riablen definieren: 

0BJ=src/Editor.o 

Die Variable muß dabei direkt am Anfang der Zeile stehen, ge¬ 
folgt von einem Gleichheitszeichen. Dahinter folgt die Aufli¬ 
stung der Objektmodule. Nun fragen Sie sich sicherlich, ob dies 
noch einen anderen Zweck hat als die Make-Datei übersichtli¬ 
cher zu gestalten. Es hat! Da wir später mit an Sicherheit gren¬ 
zender Wahrscheinlichkeit den Debugger benutzen müssen, um 
unser Programm von etwaigen Fehlern zu befreien, ist es wün¬ 
schenswert, das Programm mit der Option -w zu linken. Diese 
Option sorgt dafür, daß wir, wenn wir den Debugger benutzen. 
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auf die Namen von Funktionen und globalen Variablen zugrei¬ 
fen können, was das Debuggen für uns extrem vereinfacht. Nun 
haben wir in unserer Make-Datei zwei Link-Anweisungen, in 
denen die Namen sämtlicher Objektmodule auftauchen. Eine 
Link-Anweisung erzeugt ganz normal den Editor, während die 
andere zusätzlich eine Symboltabelle einbindet, also mit Option - 
w linkt. Verwenden wir dagegen die Variable OBJ, so brauchen 
wir die Objektmodule nur einmal zu definieren und geben bei 
den Link-Anweisungen nur die Variable an: 

OBJssrc/Editor.o 

Editor: $(OBJ) 

ln $(OBJ) -Ic -o Editor 

Debug: $(OBJ) 

ln -w $(Oej) -Ic -o Editor 

Um die Variable benutzen zu können, muß diese geklammert 
und vor die Klammer ein $ geschrieben werden. Stellen Sie sich 
nun vor, unser Programm bestände aus zwanzig Modulen (20!), 
und Sie müßten diese für beide Link-Befehle aufschreiben. So 
definieren Sie die Module einmal und können sicher sein, daß 
bei beiden Link-Anweisungen das gleiche Programm erzeugt 
wird und daß Sie kein Modul bei einer der Anweisungen ver¬ 
gessen haben. 

Wenn Sie den Editor mit der Option -w linken lassen wollen, so 
rufen Sie Make so auf: 

make Debug 

Make stellt dann fest, daß die Datei Debug gar nicht existiert 
und leitet daher alle Schritte ein, die zu deren Erzeugung laut 
Make-Datei notwendig sind. Daß dabei gar keine Datei namens 
Debug erzeugt wird, stört Make nicht. 

Aber kommen wir auf die zwanzig Module zurück, aus denen 
unser Programm bestehen könnte. Wenn Sie für jedes Objektmo¬ 
dul angeben wollten, wie dies aus dem entsprechenden Quelltext 
zu erzeugen ist, so würden Sie auch hier viel Platz vergeuden 
und sich unnötig Arbeit machen. Um dies zu verhindern, kennt 
Make Regeln. Eine Regel gibt an, wie aus einer Datei mit einer 
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bestimmten Endung (z.B.: .c) eine Datei mit demselben Namen, 
aber einer anderen Endung (z.B.: .o) zu erzeugen ist: 


.c.o: 

/• Rufe ConpUer auf */ 

Anders als bei den Abhängigkeiten wird hier zuerst die Endung 
aufgeschrieben, von der die zweite Endung abhängt. Die Rei¬ 
henfolge ist also vertauscht! Auch ist die Schreibweise anders als 
bei den Abhängigkeiten: Zuerst wird die Endung, die übriges 
mit einem Punkt beginnen muß, von der die zweite Endung ab¬ 
hängt, an den Anfang der Zeile geschrieben. Direkt dahinter 
folgt die zweite Endung, die wiederum mit einem Punkt begin¬ 
nen muß. Abgeschlossen wird die Zeile mit einem Doppelpunkt. 
In die folgenden Zeilen kommen die Anweisungen, wie Sie es 
bereits von den Abhängigkeiten her gewohnt sind. 

Da Sie bei den Regeln keine direkten Dateinamen angeben kön¬ 
nen, stellt Ihnen Make zwei Variablen zur Verfügung, die beide 
den Dateinamen enthalten, auf den diese Regel angewendet wer¬ 
den soll. Dabei entspricht $(© dem vollen Dateinamen und $* 
nur dem Namen der Datei ohne Endung und ohne Pfadname. 
Der Dateiname hat übrigens stets dieselbe Endung wie die zweite 
Endung der Regel. Nehmen wir als Beispiel src/Editor.o. Dann 
wäre $@ = src/Editor.o und $* = Editor. Stellen wir nun eine 
Regel auf, wie aus einer prelist-Datei eine pre-Datei zu erzeu¬ 
gen ist: 

.prelist.pre: 

cc *a -o ram:$*.preasm pre/$^.prelist 
delete rain:$*.preasm 

Der einzige Unterschied zur oben definierten Abhängigkeit ist, 
daß die Datei, die auf der RAM-Disk erzeugt wird, den Namen 
Editor.preasm bekommt, wenn die Datei pre/Editor.pre erzeugt 
werden soll. Nun können wir die Anweisungen, die oben auf 
unsere Abhängikeit gefolgt sind, entfernen, da diese von der 
Regel bestimmt werden. 

Die nächste Regel, die wir definieren wollen, gibt an, wie aus 
einem Quelltext eine Objektdatei zu erzeugen ist. Hier sollten 
wir beachten, daß unser Programm, wenn es auch aus mehreren 
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Modulen besteht, nur ein Hauptmodul enthält, in dem die 
Funktion main() definiert ist. Nun erlaubt es der C-Compiler 
durch Setzen des Flags +B bei allen anderen Modulen etwas 
Speicher zu sparen. Während das Hauptmodul nämlich mit einem 
Sprung in eine Initialisierungsroutine startet, ist dies bei den an¬ 
deren Modulen nicht notwendig, da diese Routine nur einmal 
vor Beginn von main auf gerufen werden muß. Wir werden die 
Regel so definieren, daß sie alle Module außer dem Hauptmodul 
erzeugen kann: 


.c.o: 

cc +B +Ipre/Eclitor.pre -0 $3 src/$*.c 

Nun Stellt unser Hauptmodul aber die Ausnahme von dieser Re¬ 
gel dar. Hier ist es jedoch ausreichend, hinter die Abhängig¬ 
keitsdefinition für das Hauptmodul src/Editor.o eine entspre¬ 
chende Anweisung zu schreiben, so wie wir es oben bereits ge¬ 
tan haben. Denn nur dann, wenn Make zu einer Abhängigkeit 
keine Anweisungen vorfindet, benutzt es eine entsprechende Re¬ 
gel. Unsere Make-Datei ist nun fertig und sie hat folgendes 
Aussehen: 

<inakefile> 


.c.o: 

cc +B +Ipre/Editor.pre -0 $S src/$*.c 
.prelist.pre: 

cc -A -0 rani:$*.preasm +H$a pre/$*.prellst 
delete rain:$*.preasm 

OBJ^src/Editor.o 

Editor: $(0BJ) ' 

ln $(0BJ) -Ic -o Editor 

Debug: $(0BJ) 

ln -w $(0BJ) -Ic -0 Editor 

pre/Editor.pre: pre/Editor.prelist 
src/Editor.o: src/Editor.c pre/Editor.pre 
cc '•■I pre/Edi tor. pre src/Editor.c 

Nehmen wir jetzt noch eine weitere Datei für den Editor in An¬ 
griff, die später häufig verwendet werden wird, nämlich die 
Datei, die die Datenstrukturen des Editors definiert: 
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<src/Editor.h> 


^************ 

* 

* Includes: 

* 


#include <exec/types.h> 


^******************* 

* 

* Datenstrukturen: 

* 

******************* j 


struct Zeile 

< 

struct Zeile *succ; 
struct Zeile *pred; 
UBYTE flags; 

UBYTE len; 

>; 


#define ZLF^USED 128 

Diese Datei enthält momentan nur die Definition für Zeilen, was 
sich aber noch ändern wird. Die Make-Datei müssen wir auch 
dementsprechend anpassen: 

<makefile> 


.c.o: 

cc +B +Ipre/Editor.pre -0 $9 src/$*.c 
.prelist.pre: 

cc -A -0 ram:$*.preasm +H$a pre/$*.prelist 
delete ram:$*.preasm 

OBJ=src/Editor.o 

Editor: $(0BJ) 

ln $<0BJ) -Ic -o Editor 

Debug: $(0BJ) 

ln -w S(OBJ) -Ic -o Editor 

pre/Editor.pre: pre/Editor.prelist src/Editor.h 
src/Editor.o: src/Editor.c src/Editor.h pre/Editor.pre 
cc '•‘Ipre/Editor.pre src/Editor.c 



528 


Das große C-Buch zum Amiga 


Editor.h wird also momentan von Editor.pre und Editor.o be¬ 
nutzt. Um besser zu verstehen, was beim Aufruf von Make pas¬ 
siert, geben Sie doch mal Editor.c, Editor.h, Editor.prelist und 
das "makefile" ein. Nun müssen Sie noch Make auf Ihre Diskette 
kopieren und dann "make Editor" aufrufen. Zuerst stellt Make 
dann fest, daß Editor von src/Editor.o abhängt, welches noch 
nicht existiert. Daraufhin merkt sich Make, daß es src/Editor.o 
erzeugen muß und stellt fest, daß dieses von src/Editor.c, 
src/Editor.h und pre/Editor.pre abhängt. Während die beiden 
ersten Dateien bereits existieren, ist dies bei der dritten Datei 
nicht der Fall. Also merkt sich Make wieder, daß es pre/Editor. 
pre erzeugen soll, und schaut nach, wovon dieses abhängt. 
pre/Editor.pre hängt von pre/Editor.prelist und von src/Editor.h 
ab. Da beide existieren, kann Make aufgrund der Regel ".pre- 
list.pre" die Datei pre/Editor.pre erzeugen, indem es den folgen¬ 
den Befehl ans CLI schickt: 

cc -A -0 rancEditor.preasm +Hpre/Editor.pre pre/Editor.prelist 
und danach die überflüssige Datei ram:Editor.preasm löscht: 

delete ram:Editor.preasm 

Nachdem nun pre/Editor.pre existiert, kann Make src/Editor.o 
erzeugen, und es führt daher folgenden Befehl aus: 

cc '•■Ipre/Editor.pre src/Editor.c 

Zwar gibt es auch eine Regel, um aus einer *.c-Datei eine Ob¬ 
jektdatei zu machen, da wir aber für src/Editor.o extra eine 
Anweisung angegeben haben, wird die Regel ignoriert. Zum 
Schluß wird dann noch der Editor selbst erzeugt, nachdem die 
Objektdatei ja existiert: 

ln src/Editor.o -Ic -o Editor 

Damit haben wir nun nicht nur die allererste Version unseres 
Programms fertig, sondern auch eine stabile Grundlage, auf der 
aufbauend wir uns der weiteren Programmierung des Editors 
widmen können. 
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4.3 Schritt für Schritt 

Im folgenden werden wir beschreiben, wie wir Schritt für 
Schritt den Editor aufbauen, bis wir am Ende soweit sind, die¬ 
sen benutzen zu können. 


4.3.1 öffnen eines Fensters 

Zuerst soll unser Editor ein Fenster öffnen. Nun könnten wir 
dazu eines der Beispielprogramme aus Kapitel 2 kopieren und 
entsprechend unseren Wünschen anpassen. Da wir später jedoch 
mehrere Fenster öffnen können wollen, müssen wir ohnehin 
unsere eigenen Routinen schreiben, die ein Fenster öffnen und 
dieses in eine zuvor beschaffte Editor-Struktur einbinden. Des 
weiteren brauchen wir eine Funktion, die ein Fenster wieder 
schließt und die dazugehörige Editor-Struktur freigibt. 

Doch zunächst zum öffnen eines Fensters. Als erstes soll diese 
Funktion versuchen, sich Speicher für die Editor-Struktur zu 
beschaffen. Ist dies gelungen, so wird ein Fenster geöffnet und 
der Zeiger auf dieses Fenster in die Struktur eingetragen. Dann 
muß die Struktur initialisiert werden, was insbesondere für die 
Speicherblock- und Zeilen-Listen gilt. Die Funktion zum 
Schließen des Fensters schließt analog zuerst das Fenster und 
gibt dann den Speicher wieder frei, den die Editor-Struktur be¬ 
setzt hatte. 

Im Prinzip wäre das schon alles, aber... wenn wir es wirklich so 
machen würden, so hätten wir später, wenn wir tatsächlich 
mehrere Fenster einbauen, einige Änderungen vorzunehmen. 
Vergegenwärtigen wir uns daher nochmals, wie das mit den Ein¬ 
gaben über Fenster funktioniert. Jedes Fenster besitzt einen 
MessagePort, an den das Betriebssystem seine Nachrichten 
schickt. Jedes Fenster! Da auch aus der IntuiMessage-Struktur 
hervorgeht, an welches Fenster eine Nachricht geschickt worden 
ist, würde für unsere Zwecke ein MessagePort ausreichen. Somit 
sparen wir kostbaren Speicher, den wir noch anderweitig "ver¬ 
geuden" wollen. 
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Eigener MessagePort 

Wir müssen also Intuition klarmachen, daß wir für alle unsere 
Fenster einen einzigen MessagePort haben wollen. Zu diesem 
Zweck löschen wir die IDCMP-Flags in der NewWindow- 
Struktur, bevor wir OpenWindow aufrufen. Da das Fenster 
scheinbar keine Eingaben erhalten soll, kriegt es von Intuition 
auch keinen MessagePort. Ist ein Fenster geöffnet worden, so 
tragen wir die Adresse unseres MessagePorts, den wir zuvor von 
CreatePort haben initialisieren lassen, in das Feld UserPort der 
Window-Struktur ein. Danach rufen wir ModifylDCMP auf und 
definieren die Eingaben, die wir erhalten wollen. Da Intuition 
bereits einen MessagePort für das Fenster vorfindet, beschafft es 
keinen neuen. Voilä! Nur beim Schließen des Fensters müssen 
wir aufpassen und das Feld UserPort der Window-Struktur auf 
Null setzen, bevor wir CloseWindow aufrufen, da sonst auch 
unser MessagePort geschlossen werden würde. 

Damit die nächste Stufe unseres Programms nicht allzu sinnlos 
wird, lassen wir uns die gedrückten Tasten anzeigen. Hierfür 
bietet das Betriebssystem zwei Möglichkeiten an: VANILLAKEY 
und RAWKEY. Während Sie bei VANILLAKEY direkt die 
ASCII-Codes der entsprechenden Tasten erhalten, erhalten Sie 
bei RAWKEY nur sogenannte Scan-Codes, die angeben, welche 
Taste gedrückt wurde, und nicht, welchem Buchstaben dies 
entspricht. In unserem Editor werden wir mit RAWKEY arbei¬ 
ten, da dies die einzige Möglichkeit ist zu erfahren, ob die 
Funktions- oder Cursor-Tasten gedrückt wurden. Diese werden 
von VANILLAKEY "verschluckt", da diese Tasten keine ASCII- 
Codes senden. 

Doch zuerst komplettieren wir die Strukturen, die wir für unse¬ 
ren Editor brauchen und die wir in Editor.h eingetragen haben: 

<src/Editor.h> 

y************ 

* 

* Includes: 


************ g 
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#include <exec/types.h> 

#include <intuition/intui1 1 on.h> 

^*********** 

* 

* Defines: 

* 

*********** ! 

#define MAXBREITE 80 

^******************* 

* 

* Datenstrukturen: 

* 

******************* j 


struct Zeile 
C 

struct Zeile *succ; 
struct Zeile *pred; 
UBYTE flags; 

UBYTE len; 

>; 

#define ZLF^USED 128 

struct ZList 

< 

struct Zeile ♦head; 
struct Zeile *tail; 
struct Zeile *tailpred; 

>; 


struct Speicherstueck 
C 

struct Speicherstueck ♦succ; 
struct Speicherstueck *pred; 
UWORD len; 

>; 

struct FList 
C 

struct Speicherstueck *head; 
struct Speicherstueck *tail; 
struct Speicherstueck *tailpred; 

>; 

struct Speicherblock 
C 

struct Speicherblock *succ; 
struct Speicherblock *pred; 

ULONG laenge; 

ULONG frei; 
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struct FList frei liste; 

>; 


struct BList 
C 

struct Speicherblock *head; 
struct Speicherblock *tail; 
struct Speicherblock *tailpred; 

>; 


struct Editor 
i 

struct Editor *succ; 
struct Editor *pred; 
struct Window *window; 
struct BList block; 
struct ZList Zeilen; 

UBYTE pufferCMAXBREITE]; 
UBYTE tabstring[MAXBREITE]; 
UUORD anz^zeilen; 
struct Zeile ^aktuell; 
struct Zeile *top; 

UWORD toppos; 

UUORD xpos^ypos; 

UWORD changed:1; 

UWORD insert:1; 

>; 


struct EList 
L 

struct Editor *head; 
struct Editor *tail; 
struct Editor *tailpred; 

>; 

Die Strukturen sind ja bereits in Kapitel 4.1 beschrieben wor¬ 
den, bis auf die letzte. Die EList-Struktur dient zum Verwalten 
aller Editorfenster, so wie die BList-Struktur zum Verwalten al¬ 
ler Speicherblöcke und die ZList-Struktur zum Verwalten aller 
Zeilen dient. Als nächstes folgt der Quelltext des Editors, der 
ebenfalls an Umfang gewonnen hat: 


<src/Editor.c> 


/************ 

* 

* Includes: 

* 

************! 
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#include <exec/types.h> 

# 1 nclude <intuition/intuition.h> 
#include ”src/Editor.h” 


y*********** 

* 

* Defines: 

* 

*********** j 


#define REV 33L 


y********************** 

* 


* Externe Funktionen: 

* 

********************** j 


struct Library *OpenLibrary(); 
struct Window *OpenWindow(); 

void CloseLibrary(),NewList(),Addlail(),CIoseWindow(),free(); 

void DeletePort(),ModifyIDCHPO«ReplyHsg(); 

struct Editor *maUoc(),*ReinHead(); 

struct MsgPort *CreatePort(); 

struct IntuiMessage *GetHsg(); 

ULONG UaitO; 

y********************* 

* 

* Globale Variablen: 

* 

********************* j 

struct Library *IntuitionBase = NULL, 

♦GfxBase = NULL, *DosBase = NULL; 

struct EList editorList; 

struct NewWindow newEdWindow = 

< 

100,50,440,156, 

AUTOFRONTPEN,AUTOBACKPEN, 

REFRESHWINDOW j HOUSEBUTTONS j RAWKEY j CLOSEWINDOW, 
WINDOWSIZING j WINDOWDRAG j WINDOWDEPTH | 

WINDOWCLOSE j SIZEBBOTTOM 
I SIMPLE REFRESH | ACTIVATE, 

NULL,NULL, 

(UBYTE ’^)*'Editor'*, 

NULL,NULL, 

100,50,640,256, 

WBENCHSCREEN 

>; 
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struct MsgPort ^edUserPort = NULL; 


* * 

* Funktionen: * 

* * 

*************** y 


* 


* OpenEditorO 

* 

* öffnet Editor-Fenster und 

* initialisiert Editor-Struktur 

* 

* Gibt Zeiger auf Editor-Struktur 

* zurück, oder NULL falls Fehler. 

* 


***********************************^ 


struct Editor ♦OpenEditorO 
i 

regiSter struct Editor *ed = NULL; 
regiSter struct Window ♦wd; 
regiSter ULONG flags; 

/♦ IDCMPFlags retten, in Struktur auf NULL setzen! 
*> eigenen UserPort verwenden! */ 
flags s newEdWindow.IDCMPFlags; 
newEdWindow.IDCMPFlags > NULL; 

/* Speicher für Editor-Struktur beschaffen: ♦/ 
if (ed - malloc(sizeof(struct Editor))) 

/* Fenster öffnen: */ 

if (wd = OpenWindowC&newEdWindow)) 

ed->window - wd; 

/♦ UserPort einrichten: V 
wd->UserPort = edUserPort; 
ModifyIDCMP'(wd,flags); 

/♦ Parameter initialisieren: V 
NewList(&(ed->block)); 

NewList(&(ed->zeilen)); 
ed->anz_zeilen = 0; 

ed->aktüell = NULL; 

ed->top = NULL; 

ed->toppos = 0; 

ed->xpos =1; 

ed->ypos = 1; 

ed->changed = 0; 

ed->insert = 1; 
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> 

eise 

C 

free(ed); 
ed :: NULL; 

> 

newEdUindow.IDCMPFlags = flags; 
return (ed); 


^*************************** 

* 

* CloseEditor(ed) 

* 

* Schließt Editor-Fenster wieder. 

* 

* ed * Editor-Struktur. 

* 


***************************! 


void CloseEditor<ed) 
struct Editor ♦ed; 

C 

ed->window->UserPort = NULL; 
CloseWindou(ed->window); 
free(ed); 


^***************** 

* 

♦ Hauptprogramn: 

* 

***************** y 

mainO 

C 

register struct Editor *ed; 

BOOL running = TRUE; 

register struct IntuiMessage *im8g; 

ULONG Signal;dass; 

UUORD code,c|ualifier; 

APTR iaddress; 
register DWORD n = 1; 

/* Librarys öffnen: V 

if ( KlntuitionBase = OpenLibrary("intuition.library",REV))) 
goto Ende; 

if ( KGfxBase = 0penLibrary(''graphiC8.library”,REV))) 
goto Ende; 

if ( KDosBase » 0penLibrary("do8.library”,REV))) 
goto Ende; 
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/* UserPort öffnen */ 

if (! (edUserPort = CreatePort(NULL,OL))) goto Ende; 

/* Editor-Liste initialisieren: V 
NewList(&editorList); 

/* Erstes Editorfenster öffnen: V 
if (ed = OpenEditorO) 

AddTai U&edi torL ist, ed); 
eise 

goto Ende; 


do 

< 

Signal = Uait(1L « edUserPort->mp_SigBit); 

uhile (imsg - GetHsg(edUserPort)) 

< 

dass = imsg->Class; 

Code s iinsg->Code; 
qualifier = imsg->Qualifier; 
i address = iinsg->I Address; 

ReplyMsg(iinsg); 

/* Event bearbeiten: V 
switch (dass) 
i 

case RAUKEY: 
printf( 

”%3d RawKey-Event: Code = $%4x, 

Qualifier = $X4x.\n», 
n++,Code,qualifier); 
break; 

case CLOSEWINDOW: 
running = FALSE; 
break; 

default: 

printf(**Nicht bearbeitbarer Event: Xlx\n",class); 

> /* of case V 
> /* of while (GetMsgO) */ 

> while (running); 

Ende: 

/* Alle Editorfenster wieder schlieBen: */ 
while (ed = RefnHead(&edi torL ist)) 

Clo8eEditor(ed); 

/* UserPort schließen: V 
if (edUserPort) DeletePort(edU8erPort); 
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/* Librarys schließen: V 
if (DosBase) CloseLibrary(DosBase); 
if (GfxBase) CloseLibrary(GfxBase); 
if (IntuitionBase) CloseLibrary(IntuitionBase); 

> 

Die Funktion OpenEditor funktioniert genauso, wie wir es fest¬ 
gelegt haben, ebenso CloseEditor. Im Hauptprogramm öffnen 
wir zuerst wieder die Librarys und dann einen eigenen Message- 
Port (edUserPort), der bei OpenEditor in den UserPort des Fen¬ 
sters eingetragen wird. Danach wird die Editorliste (editorList) 
initialisiert und ein Editorfenster geöffnet und in die Editorliste 
eingebunden (AddTail). Anschließend folgt die Hauptschleife, in 
der auf Eingaben gewartet wird. Hier ist es von Vorteil, daß wir 
nur einen MessagePort haben, denn sonst müßten wir die Si- 
gnalFlags aller Ports holen und miteinander ver-"odern", damit 
auch wirklich auf Messages aus allen Fenstern gewartet wird. 

In der Hauptschleife (do (...) while (running)) wird zunächst 
darauf gewartet, daß das Betriebssystem ein Ereignis signalisiert 
(Wait). Anschließend werden solange Messages abgeholt 
(GetMsg), bis keine mehr vorhanden sind; es kann nämlich sein, 
daß der Editor nur ein Signal, aber mehrere Messages erhalten 
hat. In dem switch-case-Befehl wird dann nach dem Message- 
Typ unterschieden und dementsprechend gehandelt. In unserem 
Fall wird bei RAWKEY nur der Code der gedrückten Taste aus¬ 
gegeben, ein Zähler (n) herauf gezählt, bei CLOSEWINDOW run¬ 
ning auf FALSE gesetzt und damit das Programm beendet. Zum 
Schluß werden zuerst alle Editorfenster wieder geschlossen, dann 
der MessagePort und zu allerletzt die Librarys. 

Ein paar Bemerkungen zum Programm: 

Um Programme zu schreiben, die wirklich auf allen Com¬ 
pilern laufen, sollten Sie die Variablentypen aus 
<exec/types.h> verwenden und nicht die normalen C-Stan- 
dard-Datentypen, da vor allem der Datentyp integer je 
nach Compiler mal als 16 Bit und mal als 32 Bit imple¬ 
mentiert ist. 

Wenn Sie sich Casting (Zwangs-Typ-Umwandlung) erspa¬ 
ren wollen, so können Sie Funktionen so deklarieren, wie 
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Sie wollen. Insbesondere Funktionen, die Zeiger auf Ob¬ 
jekte zurückliefern, können so deklariert werden, daß sie 
Zeiger auf alles mögliche zurückliefern, wie es im Pro¬ 
gramm mit malloc, RemHead und GetMsg gemacht wurde. 

Sie sollten unbedingt alle Funktionen, die Sie im Pro¬ 
gramm benutzen, auch deklarieren, und sei es nur als void. 
Andernfalls kann es allzuleicht passieren, daß Sie eine 
Funktion übersehen und es deswegen zum Programm¬ 
absturz kommt, weil Sie z.B. statt eines 32-Bit-Zeigers nur 
einen 16-Bit-Wert erhalten haben. Auch gibt es dann keine 
Probleme, wenn Sie, aus welchen Gründen auch immer, 
statt mit 16-Bit-Integer plötzlich mit 32-Bit-Integer rech¬ 
nen müssen oder umgekehrt. 

Der oft verteufelte Befehl goto erfüllt im Zusammenhang 
mit der Fehlerbehandlung seinen Zweck besser, als eine 
Aneinanderreihung von If-Befehlen. Auch das nicht un¬ 
beliebte: 

if (fehler) 
i 

C l oseU i nck>w( XXX ); 

CloseL 1 brary(yyy); 
exit(FALSE); 

> 

das für jeden Fehler im Hauptprogramm einmal hinge¬ 
schrieben wird, ist, was den Speicherbedarf betrifft, im 
Vergleich mit goto um ein Vielfaches uneffizienter, denn 
schließlich wollen die entsprechenden Befehle vor dem exit 
auch codiert werden. Die Verwendung von gotos spart hier 
Speicher und ist sicherlich nicht unübersichtlicher. 

Die Funktionen NewList, AddTail und RemHead sind ei¬ 
gentlich für Exec-Listen gedacht. Wenn Sie sich die 
Strukturen von Lists und Nodes ansehen (siehe Anhang: 
Exec-Library), so werden Sie feststellen, daß diese mini¬ 
mal umfangreicher sind als unsere Strukturen. Allerdings 
funktionieren die genannten Funktionen auch mit unseren 
Strukturen, da diese nicht auf die zusätzlichen Elemente 
zugreifen. Anders wäre dies, wenn wir auch die Funktion 
Enqueue benutzen würden, da diese auch das Prioritätsfeld 
der Exec-Node benutzt, das unsere Struktur nicht besitzt. 



Betriebssystemprogrammierung 


539 


Probieren Sie das Programm doch einmal aus, und drücken Sie 
ein paar Tasten. Wie erwartet erhalten Sie je eine Message für 
das Drücken und eine für das Loslassen der Taste. Wenn Sie 
jetzt aber eine Taste drücken und gedrückt halten, so passiert 
etwas, was Sie vielleicht nicht unbedingt erwartet haben. Sobald 
eine gewisse Zeitspanne vergangen ist (der sogenannte 
KeyRepeatDelay), erhalten Sie plötzlich reihenweise weitere 
Messages für diese Taste, und zwar so lange, bis Sie die Taste 
wieder loslassen. Der einzige Unterschied zu der ersten Message 
für diese Taste ist, daß beim Qualifier das neunte Bit gesetzt ist, 
was bedeutet, daß diese Taste aufgrund der Tastaturwiederhol¬ 
funktion gesendet wurde. 

Eine Wiederholfunktion der Tastatur hätten Sie wahrscheinlich 
nur bei VANILLAKEY-Messages erwartet? Für unseren Editor 
ist dies aber nur von Vorteil, da wir nun die Tastaturwieder¬ 
holfunktion nicht per Hand programmieren müssen. Stellt sich 
nur noch die Frage, wie wir die RAWKEYs in normale ASCII- 
Zeichen umwandeln können. Eine eigene Umwandlungstabelle 
scheidet mit Sicherheit aus, da diese nicht auf Amigas mit an¬ 
deren Tastaturbelegungen funktionieren würde. Aber auch hier 
stellt das Betriebssystem erfreulicherweise eine Funktion zur 
Verfügung, die uns diese Aufgabe abnimmt, und dabei die ein¬ 
gestellte Tastaturbelegung berücksichtigt. 


4.3.2 Von RAWKEY nach ASCII 

Die Funktion ist Teil des Console.Devices und hört auf den Na¬ 
men RawKeyConvert. Allerdings brauchen wir nicht das Con- 
sole.Device zu öffnen, um an diese Funktion zu kommen, son¬ 
dern es reicht aus, einen Zeiger auf die ConsoleBase zu holen, 
da sich die Funktion wie eine Funktion einer Library auf rufen 
läßt. Den Zeiger auf die ConsoleBase erhalten wir, indem wir 
zuerst 


OpenConsole("console.device",-1L,IOStdReq,OL}; 

aufrufen und uns dann den Zeiger aus dem io_Device-Feld der 
lOStdReq-Struktur holen. Danach können wir RawKeyConvert 
wie eine normale Funktion aufrufen. Übergeben müssen Sie da- 
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bei einen Zeiger auf eine InputEvent-Struktur, einen Zeiger auf 
einen Puffer, dessen Länge und einen Zeiger auf eine KeyMap- 
Struktur, den wir aber vorerst auf Null setzen, da zur Konver¬ 
tierung die Standard-Tastaturtabelle verwendet werden soll. Die 
InputEvent-Struktur müssen wir vor dem Aufruf füllen, und 
zwar mit dem RAWKEY-Key-Code und dem Qualifier aus der 
IntuiMessage-Struktur. Um vom Programm statt der Rawkeys 
nun die ASCII-Zeichen ausgeben zu lassen, sind folgende Än¬ 
derungen notwendig: 

Zuerst definieren wir die maximale Länge einer Tastatureingabe 
auf 128 Zeichen, was sicher nicht zu wenig ist: 

#define MAXINPUTLEN 128L 

Dann deklarieren wir die beiden Funktionen OpenDevice und 
RawKeyConvert, die neu in unserem Programm sind: 

ULONG OpenDeviceO; 

SHORT RawKeyConvertO; 

Jetzt kommen noch ein paar globale Variablen dazu, die wir 
bereits besprochen haben. In der InputEvent-Struktur setzen wir 
das ie_Class-Feld auf RAWKEY, damit wir dies nicht explizit 
im Programm tun müssen: 

struct lOStdReq ioStdReq; 

UBYTE inputPuffer[MAXINPUTLEN]; 

UUORO inputLen = 0; 

struct InputEvent inputEvent = 

C 

0 , 

lECLASS RAUKEY,0, 

0,0 

>; 

Im inputPuffer werden von der Funktion RawKeyConvert die 
Zeichen abgelegt, mit der die entsprechende Taste belegt ist. Zu 
Beginn des Hauptprogramms definieren wir eine Variable 1, die 
wir später noch brauchen werden: 


SHORT l; 



Betriebssystemprogrammierung 


541 


Im Hauptprogramm holen wir uns den Zeiger auf das Con- 
sole.Device, nachdem wir die Librarys geöffnet haben: 

if ( !(0penDevice(“console.device*',-1L,&ioStclReq,0L))) 

ConsoleDevice = ioStdReq.io_Device; 
eise 

goto Ende; 


Und zu guter Letzt bauen wir in der Hauptschleife die Behand¬ 
lung von RAWKEY-Messages folgendermaßen um: 

case RAUKEY: 

if (! (Code & lECODE UP PREFIX» 

inputEvent.ie_Code = code; 
inputEvent-ie^Qualifler = qualifier; 
if (d = RawKeyConvert(&inputEvent, 

1 nputPuf fer,MAXINPÜTLEN,NUL L) 

) > 0 ) 
i 

inputPufferCl] = 0; 

printf(*‘X3d> Laenge = Xd: 

for (1*0; inputPufferCl]; 1++) 

pr i nt f (”X2x**, < UWORD) i nputPuf f er [ l ]) ; 
if (inputPufferCO] >= 32 && inputPuffer[0] <= 127) 
printfC“ Xs”,inputPuffer); 
printf("\n**); 

> 

> 

break; 


Zuerst testen wir, ob die entsprechende Taste gedrückt oder los¬ 
gelassen worden ist; im zweiten Fall (IECODE_UP_PREFIX) 
interessiert sie uns nicht. Dann werden die Werte von code und 
qualifier in die InputEvent-Struktur übertragen, und an¬ 
schließend wird RawKeyConvert auf gerufen. Den Rückgabewert 
speichern wir in 1, nicht in inputLen, ab und testen, ob dieser 
größer als 0 ist. War er kleiner null, so ist ein Fehler aufgetreten 
(Puffer war zu klein), und war er null, so ergab die Taste keine 
Zeichen, so daß wir uns in beiden Fällen nicht weiter darum zu 
kümmern brauchen. 

War der Rückgabewert jedoch größer als null, so gibt er die 
Länge des Strings an, mit dem die Taste belegt ist, und wir set¬ 
zen hinter den String ein Null-Byte, damit wir diesen mit printf 
ausgeben können. Normalerweise sind die Tasten nur mit einem 
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einzigen Zeichen belegt, so daß wir als Länge den Wert Eins er¬ 
halten, aber es gibt auch Ausnahmen. Danach geben wir zuerst 
eine fortlaufende Nummer und dann die Länge des Strings aus. 
Es folgt der String selbst, und zwar zuerst in Hex-Codes und 
dann als richtiger ASCII-String, aber dieser nur, wenn das erste 
Zeichen zwischen einem Space und einem Delete liegt, also ein 
druckbares Zeichen ist. Wenn wir diese Abfrage nicht treffen, 
wird unsere Ausgabe im CLI-Fenster in Mitleidenschaft gezo¬ 
gen, da das CLI z.B. bestimmte ASCII-Codes in Cursor-Bewe¬ 
gungen umsetzt. 

Alles klar? Also los: Eintippen, compilieren und ausprobieren. 
Während das Ausprobieren der "normalen" Tasten keine unge¬ 
wöhnlichen Ergebnisse hervorbringt, erhalten Sie, wenn Sie die 
Funktionstasten drücken, drei bis vier (bei Shift) Zeichen gelie¬ 
fert. Dies müssen wir bei unserer späteren Tastaturabfrage be¬ 
rücksichtigen. Außerdem ist dies der Grund dafür, daß Sie bei 
VANILLAKEY keine Informationen über die Funktionstasten 
erhalten. Schließlich kann die IntuiMessage nur ein einziges 
Zeichen zurückliefern und nicht drei auf einmal. Wenn Sie alle 
Sondertasten ausprobieren und die gelieferten Codes mit denen 
in der Dokumentation (AmigaDOS-Manual) vergleichen, so wer¬ 
den Sie vielleicht feststellen, daß einige damit nicht überein¬ 
stimmen; aber vielleicht sind die (wenigen) Fehler in Ihrer Aus¬ 
gabe bereits behoben. 

Den kompletten Quelltext zu diesem Teil des Editors finden Sie 
im Verzeichnis VO.l auf der Diskette zum Buch. Wenn Sie Be¬ 
sitzer eines Aztec-C-Compilers sind, so können Sie diesen com¬ 
pilieren, indem Sie in das Verzeichnis VO.l wechseln und dann 
"make Editor" eingeben. Zuvor müssen Sie allerdings dafür sor¬ 
gen, daß sich Make irgendwo befindet, so daß das CLI dies auch 
wirklich aufrufen kann, z.B. indem Sie es auf die RAM-Disk 
kopieren: 

copy make to ram: 

path ram: add 

und dann zum Compilieren folgendes eingeben: 
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cd V0.1 
make Editor 

Der einzige Unterschied zu den hier besprochenen Dingen ist, 
daß das pre-Verzeichnis woanders liegt, nämlich im Hauptver¬ 
zeichnis. Da es aber nur einmal für alle Versionen des Editors 
existiert, sollten Sie darauf achten, daß die Datei :pre/£ditor.pre 
für jede neue Version des Editors auch neu erzeugt wird! Lö¬ 
schen Sie diese also vor dem Aufruf von Make. Wenn Sie den 
Editor nicht extra übersetzen wollen, so finden Sie das fertige 
Programm ebenfalls im Verzeichnis VO.l, so daß Sie diesen nur 
noch zu starten brauchen. 


4.3.3 Die Speichervervvaltung 

Nächster Punkt der Tagesordnung ist die Speicherverwaltung. 
Bevor wir eine Datei laden und anzeigen lassen können, was 
unser nächstes Ziel sein wird, müssen wir die Möglichkeit zur 
Verfügung stellen, Zeilen abzuspeichern und zu verketten. Dazu 
brauchen wir eine Funktion, die uns eine neue Zeile-Struktur 
besorgt, in die wir dann einen String, die eigentliche Zeile also, 
kopieren. Der Kopf dieser Funktion soll wie folgt aussehen; 

struct Zeile *neueZeile(len) 

UWORD len; 

Dabei ist len die Länge des Strings, einschließlich Zeilenende. 
Da wir aber nur Speicherstücke gerader Länge verwenden kön¬ 
nen, müssen wir in der Funktion die Länge geradzahlig machen. 
Da dies sicher öfter vorkommt, definieren wir ein entsprechen¬ 
des Define: 

«define EVENLEN(x) (((x)*1)&-2) 

Bevor wir die Funktion implementieren, wollen wir uns überle¬ 
gen, wie diese funktionieren soll. Wenn sich noch kein Speicher¬ 
block in der Blockliste befindet, der Textspeicher also leer ist, 
wird ein neuer Block mit 10 KByte Größe beschafft und dann 
eine Zeile geholt. Andernfalls wird direkt versucht, eine Zeile zu 
beschaffen. Mißlingt dies, so wird eine Garbage Collection 
durchgeführt, also der Speicher aufgeräumt, bevor ein zweites 
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Mal versucht wird, eine Zeile zu beschaffen. Mißlingt auch dies, 
so ist anscheinend in den vorhandenen Speicherblöcken nicht 
mehr genügend Platz für eine weitere Zeile vorhanden, und es 
wird ein neuer Speicherblock beschafft, der diesmal aber nur 5 
KByte groß ist. Wir arbeiten deshalb mit zwei unterschiedlichen 
Blockgrößen, damit wir für kleine Texte, die kürzer als 10 
KByte sind, nur einen Speicherblock benötigen. Der folgende 
Ablaufplan verdeutlicht unsere Vorgehensweise: 

Falls noch kein Speicherblock in Blockliste 
Hole neuen Block (Länge = 10 KByte) 
hole Zeile 
Fertig 
sonst 

hole Zeile 
Falls keine gefunden 
Garbage-Collection 
hole Zeile 

Falls keine gefunden 

hole neuen Block (5 KByte) 
hole Zeile 

Fertig 

Die nächste Funktion beschafft einen neuen Speicherblock: 

struct Speicherblock *neuerBlock(len) 

ULONG len; 

Konnte ein neuer Speicherblock beschafft werden, so wird des¬ 
sen Speicherblock-Struktur initialisiert und ein Zeiger auf den 
Block zurückgegeben, ansonsten wird Null zurückgeliefert. Der 
Speicherblock muß dann noch in die Speicherblock-Liste einge¬ 
fügt werden. Dazu brauchen wir jedoch noch einen Zeiger auf 
die aktuelle Editor-Struktur: 

struct Editor *aktuellerEditor; 

Der Speicherblock wird mit AllocMem beschafft und nicht mit 
der C-Standard-Funktion malloc. Dies ist günstiger, da malloc 
den beschafften Speicher in eine Liste einhängt, damit es am 
Programmende allen Speicher, der nicht explizit freigegeben 
worden ist, doch noch freigeben kann. Diese Liste kostet aber 
etwas Speicherplatz, und da wir selbstverständlich allen Speicher 
wieder freigeben, bevor wir das Programm beenden, verwenden 
wir besser AllocMem. 
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Aus demselben Grund verwenden wir auch nicht die Funktion 
AllocRemember, die die Intuition-Library zur Speicherverwal¬ 
tung zur Verfügung stellt. Der Vorteil dieser Funktion ist, daß 
sie sich allen Speicher merkt, denn man allokiert hat, und daß 
man diesen mit einem Befehl wieder freigeben kann. Allerdings 
muß wieder die Remember-Struktur mit abgespeichert werden, 
was zusätzlich Platz kostet. 

Ansonsten dürfte die Funktion keine Schwierigkeiten bereiten, 
so daß sich weitere Erklärungen erübrigen. Anders sieht dies da 
schon bei der nächsten Funktion aus: 

struct Zeile *holeZeile(len) 

UWORD len; 

Diese Funktion durchsucht alle Speicherblöcke des aktuellen 
Editors und nach einem Speicherstück, das die Zeile aufnehmen 
kann. In len wird dabei wieder die tatsächliche Länge der Zeile 
übergeben, die innerhalb der Funktion geradzahlig gemacht wer¬ 
den muß. Es stellt sich die Frage, welches Speicherstück wir 
nehmen sollen? Das erste, das groß genug ist, oder dasjenige, 
das genug Platz bietet und am nächsten dran ist? Da wir jedoch 
nicht umsonst diesen Aufwand mit den Speicherblöcken getrie¬ 
ben haben, werden wir anders Vorgehen, um die Speicherstücke 
möglichst optimal aufzuteilen: 

Zuerst versuchen wir ein Speicherstück zu finden, das exakt die 
gesuchte Länge hat. Dies ist sicherlich der optimale Fall. Hat 
dies nicht geklappt, so suchen wir das größte Speicherstück. Da¬ 
durch vermeiden wir weitgehendst den Fall, daß wir ein ohnehin 
schon kleines Speicherstück noch kleiner machen. Wenn jedoch 
ein Speicherstück so klein ist, daß, nachdem die neue Zeile da¬ 
von abgeschnitten worden ist, nicht einmal mehr genug Platz für 
die Speicherstueck-Struktur und mindestens zwei weitere Bytes 
ist, so war die Suche erfolglos. Denn der Rest muß mindestens 
so groß sein, daß man darin eine weitere Zeile ablegen kann. 

Rufen Sie sich nochmals in Erinnerung, daß jeder Speicherblock 
aus zwei Dingen besteht: den Zeilen, die darin liegen, und den 
freien Speicherstücken, aus denen der Platz für neue Zeilen ge¬ 
wonnen wird. 



546 


Das große C-Buch zum Amiga 


Die letzte Funktion, die von neueZeile benutzt wird, ist: 

struct Speicherblock *garbageCoUection(len) 

UWORD len; 

Diese Funktion reorganisiert den freien Speicher innerhalb der 
Speicherblöcke so, daß es pro Speicherblock nur noch ein einzi¬ 
ges Speicherstück mit maximaler Größe gibt. Bedenken Sie, daß 
jedes Speicherstück zehn Bytes Verwaltungsinformation benötigt 
(sizeof(Speicherstueck)). Je mehr Speicherstücke in einem Spei¬ 
cherblock existieren, um so weniger freien Speicher enthält die¬ 
ser. Die Garbage-Collection wird Speicherblock für Speicher¬ 
block durchgeführt, so lange, bis ein Speicherblock mit einem 
freien Speicherstück der Größe len Bytes gefunden ist oder bis 
das Ende der Speicherblockliste erreicht ist. War die Suche er¬ 
folgreich, so wird ein Zeiger auf den entsprechenden Speicher¬ 
block zurückgeliefert, andernfalls Null. Der Zeiger kann even¬ 
tuell dazu verwendet werden, der Funktion holeZeile das erneute 
Durchsuchen aller Speicherblöcke zu ersparen. 

Alle genannten Funktionen schreiben wir in ein neues Modul 
und nennen dieses Speicher.c. Das ganze Modul sieht wie folgt 
aus: 


<src/Speicher.c> 


^********4r*** 

* 

* Includes: 

* 

************ f 


#include <exec/types.h> 

#1 nclüde <intui 1 1 on/intuition.h> 
#inclucle <exec/memory.h> 

#include **src/Editor.h** 


^*********** 

* 

* Defines: 

* 

*********** j 


#define BIGBLOCK (10240L-sizeof(struct Speicherblock)) 
#define BLOCKSIZE (5120L-sizeof(struct Speicherblock)) 
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^********************** 

* 

* Externe Funktionen: 

* 

********************** f 


struct Speicherblock *AllocMeni(); 

void NewListOfAddTail(),Refnove(),FreeMein(); 


^********************* 

* 


* Externe Variablen: 


*********************! 


extern struct Editor *aktuellerEditor; 


y*************** 

* * 

* Funktionen: * 

* * 

*************** y 


^******************************************* 

* 


* freeSpeicherblock(blk) 

* 

* Gibt den Speicher des Speicherblocks 

* wieder frei, ohne Ruecksicht auf Zeilen, 

* die noch darin liegen. 

* 


* blk “ Speieherblock. 

* 


*******************************************y 


void freeSpeicherblock(blk) 
struct Speicherblock *blk; 

< 

RefTK)ve(blk); 

FreeMefn(blk,blk’>laenge ^ sizeof(struct Speicherblock)); 

> 


^********************************************** 

* 

* neuerelock(len): 

* 

* Beschafft Speicher fuer neuen Speicherblock 

* mit len Laenge und liefert Zeiger darauf 

* Zurueck. Falls Fehler => NULL. 

* 

* len = Laenge des Speicherblocks. 

* 

**********************************************y 
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struct Speicherblock *neuerBlock(len) 

ULONG len; 

< 

register struct Speicherblock *blk; 
regiSter struct Speicherstueck *spst; 

/* Speicher beschaffen: */ 

if (blk = AllocMemden+sizeof(struct 

Spei cherblock) ,HEHF_CLEAR)) 

C 

/* Speicherblock-Struktur initialisieren: V 
blk->laenge = len; 

blk->frei = len - sizeof(struct Speicherstueck); 

NeuList(&(blk->freiliste)); 

spst > (struct Speicherstueck *)(blk -t* 1); 

AckiTail(&(blk->freiliste),spst); 
spst->len = (UUORD)blk->frei; 


return (blk); 

> 


y*********************************************** 

* 

* sucheSpeicherstueck(block,len) 

* 

* Sucht Speicherstueck mit len Laenge 

* im Block block, und liefert Zeiger darauf 

* zurueck, oder Null falls kein Platz. 

* 


* block * Speicherblock. 

* len = Laenge der Zeile (geradzahlig). 

* 




Struct Speicherstueck *sucheSpeicherstueck(block,len) 
struct Speicherblock ♦block; 

UUORD len; 

C 

register UUORD minl,l; 

register struct Speicherstueck ♦st,*fnd = NULL; 

/♦ Nur Durchsuchen, wenn ueberhaupt noch genug Platz: */ 
if ((ULONG)len <= block->frei) 

C 

/♦ Minimale Laenge, falls gefundene Laenge <> len */ 
mini = len sizeof (struct Speicherstueck) 2; 

/♦ Durchsuche Liste: V 

for (st = block->freiliste.head; st->succ; st = st->succ) 
if (d = st->len) == len) 

< 

/* Optimale Groesse gefunden: V 
fnd = st; 



Betriebssystemprogrammierung 


549 


break; 

> 

eise 

if (d >= mini) && (l > ((fnd)? fnd->len : 0))) 
/* Suche groessten Block: V 
fnd = st; 


return (fnd); 

> 



* 


* ConvertSpstToZei le(blk,st, l^) 

* 

* Wandelt Speicherstueck in Zeile um. 

* War das Stueck laenger als die Zeile, 

* so wird das Stueck verkuerzt, andernfalls 

* wird das Stueck aus der Liste entfernt. 


* blk " Speicherblock des Speicherstuecks. 

* st " Speicherstueck. 

* len = Laenge der Zeile 

* 


********************************************y 


struct Zeile *ConvertSpstToZeile(blk,st,len) 
struct Speicherblock ♦blk; 

register struct Speicherstueck *st; 
register UWORD len; 

i 

register UWORD l; 
register struct Zeile * 2 ; 

if (st->len == (l = EVENLENClen))) 
i 

/* Gefundenes Stueck passt genau: V 
Remove(st); 

z = (struct Zeile *)st; 

> 

eise 

< 

/♦ Stueck aufteilen: V 
z = (struct Zeile *) 

((UBYTE *)st sizeof(struct Speicherstueck) + st->len 
- (l += sizeof (struct Zeile)) ); 
st->len -= l; 

> 

blk->frei -= l; 

z*>flags = 0; 

2 ->len = len; 
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return ( 2 ); 

> 

y*********************************************** 

* 

* holeZeile(len) 

* 

* Versucht Zeile mit len Laenge zu beschaffen, 

* und sucht dabei alle Speicherbloecke durch. 

* Liefert Zeiger auf Zeile zurueck, oder 

* Null, falls kein Platz. 

* 

* len > Laenge der Zeile. 

* 


struct Zeile *holeZeile(len) 

UWORD len; 

C 

regiSter UWORD l; 

register struct Speicherblock *blk,*fblk = NULL; 
register struct Speicherstueck ’^st,*fst = NULL; 

/* Laenge geradzahlig machen: V 
l - EVENLEN(len); 

/* Liste der Bioecke durchlaufen: ♦/ 

for (blk = aktuellerEditor->block.head; blk->succ; 

blk s blk’>succ) 

if (st = sucheSpeiCherstueck(blk,D) 
if <st->len == l) 

< 

/* Optimales Speicherstueck gefunden: V 
fblk = blk; 
fst = st; 
break; 

> 

eise 

if (s*t->len > ((fst)? fst->len : 0)) 
i 

/* Suche groesstes Speicherstueck: V 
fblk = blk; 
fst = st; 

> 


if (fst) 

return (ConvertSpstToZeile(fblk,fst,len)); 
else 

/* Kein Stueck gefunden: V 
return (NULL); 
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^********************************************* 

* 

* optimiereBlockblock) 


* Durchsucht alle Speicherstuecke des Blocks 

* und macht aus hintereinanderliegenden 

* Speicherstuecken ein einziges. 

* 


* block Speicherblock. 

* 

******4r**************************************y 


void optimiereBlock (blk) 

register struct Speicherblock *blk; 

C 

register struct Speieherstueck *st1,*st2,*st1e; 


for (sti = blk*>freiliste.head; st1->succ; st1 = stl->succ) 
i 

/* Bestimme Zeiger direkt hinter sti: */ 
stie = (struct Speicherstueck *) 

(((UBYTE *)st1) + st1->len + sizeof(struct 

Speicherstueck)); 


for (st2 * blk->freiliste.head; st2->succ; st2 = st2->succ) 
if (stie st2) 

< 

/* Speicherstueck st2 liegt direkt hinter sti: V 
sti->len +* st2->len + sizeof(struct Speicherstueck); 
blk->frei ♦= sizeof(struct Speicherstueck); 
Remove(st2); 

stie = (struct Speicherstueck *) 

(((UBYTE *)st1)+st1->len+sizeof(struct 

Speicherstueck)); 


> 


> 


> 


/* Wieder am Anfang der Liste beginnen: V 
st2 = (struct Speicherstueck ♦) &(blk- 

>freiliste.head); 


* 

* garbageCollection(len) 

* 

* Raeumt solange den Speicher auf, 

* bis mindestens len freie Bytes. 

* Liefert Zeiger auf Speicherblock, in 

* dem noch Platz ist zurueck, oder 

* Null, falls kein Platz. 

* 



552 


Das große C-Buch zum Amiga 


* 

* 

* 


len = Anzahl Bytes, die untergebracht 
werden sollen. 


****************************************^ 


struct Speicherblock *garbageCollection(len) 

UWORD len; 

i 

struct Speicherblock *blk; 
struct SpeiCherstueck *st,spst; 
regiSter UBYTE *ptr,*end; 
register struct Zeile *z,*f 2 ; 
regiSter UWORD n; 

for (blk = aktuellerEditor->block.head; blk->succ; 

k = blk->succ) 

/* Nur Garbage-Collection, wenn mehr 

als ein Speicherstueck! */ 
if ((st = blk*>freiliste.head->succ)? st->succ : FALSE) 
i 

/* Anfang und Ende des Blockspeichers bestimmen: V 
ptr = (UBYTE *)(blk + 1); 
end = ptr blk->laenge; 

/* Zeilen an den Anfang legen: V 
while (ptr < end) 

< 

/* Suche Zeile, die am naechsten an ptr liegt: */ 
fz s NULL; 

for (z s aktuellerEditor->zeilen.head; Z‘>succ; 

z = z->succ) 

if ((z >= ptr) && (z < end)) 
if ((z < fz) II (fz « NULL)) 
fz * z; 


if (fz) 

if (fz != ptr) 
i 

/* Alte Zeiger merken: V 
z = fz; 

st s (Struct Speicherstueck *)ptr; 
spst a ♦st; 


/♦ Zeile nach ptr herunterschieben: ♦/ 
for (n = (EVENLEN(fZ'>len)*i‘8izeof(struct 

Zeile))»1; 

n; n--) 

♦((UWORD ♦)ptr)+i' » ♦((UWORD ♦)fz)++; 

/♦ Zeiger korrigieren: ♦/ 
fz a (struct Zeile ♦)st; 
fz->8ucc->pred a fz; 
fz->pred->succ a fz; 
if (aktuellerEditor->aktuell as z) 
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aktueUerEditor->aktueU = fz; 
if (aktueUerEditor->top == z) 
aktueUerEditor'>top = fz; 

st = (struct SpeiCherstueck *)ptr; 
st->succ = spst.succ; 
st->pred = spst.pred; 
st->len = spst.len; 
spst.succ->pred « st; 
spst.pred‘>succ = st; 

/* SpeiCherstuecke zusanmenschieben: */ 
optimiereBlock(blk); 

> 

eise 

/* ptr hochsetzen: */ 

ptr ♦= EVENLEN(fz->len) sizeof(struct Zeile); 

else 

/* Scheinbar keine Zeilen mehr im Block! V 
break; 

> /* of while V 

/* Teste, ob bereits genug Platz: V 
if (sucheSpeicherstueck(blk,len)) 
return (blk); 

> /♦ of if (mindestens 2 Bioecke) V 


return (NULL); 

> 


* 

* neueZeile(len) 

* 


* Beschafft Platz fuer neue Zeile, 

* in die len Zeichen passen. 

* Liefert Zeiger auf neue Zeile zurueck, 

* oder Null, falls Fehler. 

* 

* len = Anzahl der Zeichen. 


****************4r*************«r**********y 


Struct Zeile *neueZeile(len) 

UWORD len; 

i 

register struct Zeile *z; 
register struct Speicherblock *blk; 
register struct Speicherstueck *8t; 
register UWORD l; 

if (aktuel lerEditor->block.head->8iicc) 
/* Es existieren bereits Bioecke: V 
if (z s holeZeile(len)) 
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return (z); 
eise 

/* Zeile nicht direkt verfuegbar: Garbage*Collection V 
if (blk - garbageCollectionCl = EVENLEN(len))) 
if (st = sucheSpeicherstueck(blk,D) 

return (ConvertSpstToZeile(blk,st,len)); 
eise 

/* Darf eigentlich nicht auftreten !!! V 
return (NULL); 

eise 

/* Garbage’Collection erfolglos 

-> neuen Block holen V 
if (blk = neuerBlock(BLOCKSIZE)) 
i 

AddTail(&(aktuellerEditor->block),blk); 
return (holeZeile(len)); 

> 

eise 

return (NULL); 

eise 

/* Noch kein Block in der Block-Liste: V 
if (blk = neuerBlock(BIGBL(X:K)) 
i 

AddTai l(&(aktuellerEditor’>block),blk); 
return (holeZeile(len)); 

> 

eise 

return (NULL); 

> 

Es sind mehr Funktionen geworden, als wir uns eigentlich vor¬ 
genommen hatten. Dies liegt daran, daß sich einige Aufgaben 
besser in Funktionen unterbringen ließen und daß ein paar 
Kleinigkeiten von uns in der Planung nicht berücksichtigt wor¬ 
den waren. Daher nun ein paar Worte zu den zusätzlichen Funk¬ 
tionen: 

void freeSpeicherblock(blk) 
struct Speicherblock *blk; 

Diese Funktion gibt den Speicher wieder frei, den der Speicher¬ 
block blk belegt hatte. Dabei wird keine Rücksicht darauf ge¬ 
nommen, ob eventuell noch Zeilen in diesem Block liegen. Diese 
Funktion wird in CloseEditor dazu benutzt werden, den ge¬ 
samten Speicher des Editors wieder freizugeben. 

struct Speicherstueck *8ucheSpeicher8tueck(block,len) 

8truct Speicherblock *block; 

UUORD len; 
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Diese Funktion durchsucht den angegebenen Block nach einem 
Speicherstueck, das möglichst genau die Länge len hat, ansonsten 
nach dem größten vorhandenem Speicherstueck. Zurückgeliefert 
wird ein Zeiger auf das gefundene Speicherstueck oder Null, 
falls keines mit ausreichender Länge gefunden wurde. Zu be¬ 
achten ist insbesondere, daß blk->frei die Summe der Längen 
der einzelnen Speicherstuecke dieses Blocks enthält, so daß sich 
eine erste grobe Abfrage, ob in dem Block überhaupt noch ge¬ 
nug Platz vorhanden ist, entsprechend einfach gestaltet. Konnte 
die Länge nicht genau gefunden werden, so sind nur die größe¬ 
ren Speicherstuecke von Interesse, die um (sizeof(struct Spei¬ 
cherstueck) + 2) Bytes größer sind als len, da das gefundene 
Speicherstueck in eine Zeile und ein Speicherstueck auf geteilt 
werden muß. Wenn aber kein Platz mehr für die Strukturen ist, 
so kann er auch nicht aufgeteilt werden! 

Für alle, denen die folgende Zeile Schwierigkeiten bereitet, hier 
ein kleiner Tip: 

if (<l >= mini) && (l > ((fnd)? fnd->len : 0))) 

Wenn fnd gleich null ist, also noch kein Speicherstueck gefunden 
worden ist, kann nicht getestet werden, ob 1 größer als die 
Länge des bereits gefundenen Speicherstückes (fnd) ist. In die¬ 
sem soll auf jeden Fall der zweite Vergleich TRUE sein. Der 
seltsame Ausdruck ((fnd)? fnd->len : 0) ist null, wenn auch fnd 
null ist, und sonst fnd->len, also die Länge des Speicherstückes 
fnd. Da 1 aber immer positiv ist, ist 1 > 0 immer TRUE, und 
somit haben wir den Sonderfall, daß fnd noch null ist, elegant 
umgangen. 

struct Zeile *ConvertSpstToZeile(blk,st,len) 

struct Speicherblock *blk; 

struct Speicherstueck *st; 

UWORD len; 

Wenn wir eine neue Zeile beschaffen wollen, so müssen wir 
zwangsweise ein Speicherstueck in eine Zeile umwandeln oder 
doch zumindest eine Zeile von einem Speicherstück abschneiden. 
Diese Arbeit nimmt uns die zuvor genannte Funktion ab. War 
das Speicherstück genauso lang wie die Zeile, so wird es aus der 
Liste aller Speicherstücke entfernt, andernfalls wird die Zeile 
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vom Ende des Speicherstücks abgezwackt und dessen Länge 
entsprechend verringert. In jedem Fall wird die Anzahl der 
freien Bytes des Blocks, zu dem das Speicherstück gehört, ent¬ 
sprechend vermindert. Zurückgeliefert wird ein Zeiger auf die 
Zeile. 


void optimiereBlock (blk) 
struct Speicherblock *blk; 

Die einzige Aufgabe der Funktion ist es, direkt hintereinander 
liegende Speicherstücke zusammenzufügen. Diese Funktion 
brauchen wir immer dann, wenn wir ein Speicherstück verlän¬ 
gern oder ein neues Speicherstück in die Liste einhängen. Dann 
nämlich müssen wir sicherstellen, daß keine zwei Speicherstücke 
direkt hintereinander liegen, da dies uns jedesmal zehn Bytes 
(sizeof(struct Speicherstueck)) kostet. 

Zur Funktion garbageCollection gibt es allerdings noch etwas zu 
sagen, da wir uns bei der Festlegung der Aufgaben dieser Funk¬ 
tion ziemlich kurz gefaßt haben. Diese Funktion arbeitet in etwa 
wie folgt: 

FOR alle Blöcke 

Liegen in diesem Block mindestens zwei Speicherstücke? 

Schiebe alle Zeilen, die in diesem Block liegen, 
an dessen Anfang. 

Fasse alle Speicherstücke zu einem zusammen. 

Ist in diesem Block bereits genug Platz? 

Liefere Zeiger auf Block zurück. 

Sonst: Liefere Null zurück. 

Dabei ist vor allem das Zusammenschieben aller Zeilen an den 
Blockanfang so eine Sache. Existieren irgendwo im Programm 
Zeiger auf diese Zeile, so müssen diese umgebogen werden, so 
wie dies auch mit der Verkettung geschieht. Im Moment könnten 
dies höchstens die beiden Zeiger aktuell und top aus der Editor- 
Struktur sein, die wir später für die Ausgabe und das Editieren 
brauchen. Wenn wir später jedoch weitere Zeiger auf Zeilen in 
das Programm einfügen, so müssen wir diesen Umstand unbe¬ 
dingt beachten, sonst stimmt nach einer Garbage Collection gar 
nichts mehr. 
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4.3.4 Testumgebung 

Jetzt müssen wir nur noch die Funktionen austesten, die uns das 
Modul Speicher zur Verfügung stellt. Allerdings können wir dies 
nicht so ohne weiteres, da wir nicht überprüfen können, ob un¬ 
sere Funktionen auch wirklich richtig funktionieren. Darum 
schreiben wir eine Testumgebung, von der aus wir alle wichtigen 
Funktionen aufrufen können und die uns den belegten Speicher 
anzeigt: 


<src/Test.c> 


/************ 

* 

* Includes: 

* 

************ j 

#include <exec/types.h> 

#inclüde <intuition/intuition.h> 
#include **src/Editor.h“ 

y*********** 

* 

* Defines: 

* 

*********** y 


y********************** 

* 

* Externe Funktionen: 

* 


struct Zeile *neueZeileO; 
UBYTE *gets(),getchar(); 
UWORD strlenO; 
void strcpyO, AddTailO; 

^********************* 

* 

* Externe Variablen: 

* 

*********************/ 


extern struct Editor *aktuellerEditor; 
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^*************** 
* ★ 

* Funktionen: * 

* * 


void printO 
i 

register struct Zeile *z; 

for (z = aktuellerEditor->zeilen.head; z->succ; z = 
pr i nt f (**%s\n**, z+1) ; 

> 

void print_blocks() 
i 

register struct Speicherblock *blk; 
pr i nt f < "B l ock l i s t e: \n\n'*) ; 

for (blk = aktuellerEditor*>block.head; blk->succ; 

blk = blk->succ) 

printf('*Block %8lx, Laenge = Xld, Frei = Xld\n", 
blk,blk->laenge,blk->frei); 

printf(**\n**); 

> 

void inputO 
i 

UBYTE s[80]; 

register struct Zeile *z; 
register DWORD l; 

printf<”Neue Zeile: ”); 
if (gets(s)) 

< 

l = strlen(s) + 1; 
if (z = neueZeile(l)) 
i 

strcpy<z+1,s); 

AddTail(&(aktuellerEditor->zeilen),z); 

> 

eise 

printf(**Fehler bei neueZeilei 1 i\n"); 

> 

eise 

printf("Fehler bei gets!!!\n”); 

> 

void Teste) 
i 

UBYTE c; 


z->succ) 


while ((c = getcharO) != 27) 
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t 

while (getcharO 1» 10) ; /* CR einiesen! */ 

switch (c) 

case ’a': 
inputO; 
break; 
case ’p': 
printO; 
break; 
case ’b': 

print_blocks(); 

break; 

> 

> 

> 

Die Funktion print gibt dabei den gesamten Text aus, den wir 
eingegeben haben. Die Funktion print_blocks gibt die Start¬ 
adressen, Längen und die Anzahl der freien Bytes aller 
Speicherblöcke aus, die der Editor momentan belegt hat. input 
dagegen erwartet die Eingabe einer Zeile, die dann ans Ende der 
Liste aller Zeilen angefügt wird. Anders, als wir es später im 
richtigen Editor machen werden, gehört auch ein Null-Byte als 
Zeilenabschluß mit zu der Zeile, dies aber nur, um die Ausgabe 
aller Zeilen bei print so einfach wie möglich zu gestalten. Dort 
erwartet die Funktion printf nämlich einen Zeiger auf einen 
String als Parameter, der durch ein Null-Byte abgeschlossen ist. 

Aufgerufen werden diese Funktionen von der Funktion Test aus, 
die von Ihnen die Eingabe eines Zeichens erwartet. So können 
Sie mit a (Append) eine Zeile anfOgen, mit p (Print) den bis¬ 
herigen Text ausgeben und mit b (Blocks) eine Liste aller 
Speicherblöcke erhalten. Nach dem Drücken des Buchstabens 
müssen Sie allerdings noch Return betätigen, da das CLI-Fen- 
ster, über das diese Eingaben laufen, zeilenorientiert arbeitet 
und Eingaben erst nach dem Drücken der Return-Taste an das 
Programm abschickt. Da uns das Return jedoch stört, wird es 
vor dem Switch-Case abgeschnitten. 

Jetzt müssen wir nur noch unser Hauptprogramm so ändern, daß 
die Funktion Test automatisch aufgerufen wird. Wir ändern das 
Modul Editor daher wie folgt: 
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Zuerst definieren wir die externen Funktionen: 

void TestO; 

void freeSpeicherblockO; 

Dann ändern wir die Funktion CloseEditor so, daß auch wirklich 
aller Speicher freigegeben wird: 

void CloseEditor(ed) 
struct Editor *ed; 

C 

regiSter struct Speicherblock *blk; 

/* Zuerst Speicherblöcke wieder freigeben: */ 
uhile (blk = (struct Speicherblock *)RefnHead(&(ed’>block))) 
freeSpeicherblock(blk); 

/* Dann Fenster schliessen: */ 
ed->window->UserPort = NULL; 

CloseWindow(ed->window); 
free(ed); 


Und im Hauptprogramm rufen wir vor der Hauptschleife, also 
vor dem Wait-Befehl, die Funktion Test auf: 

Teste); 

Und zu guter Letzt ändern wir noch das Make-File ab, so daß 
die beiden neuen Module auch mit übersetzt werden. Dazu er¬ 
gänzen wir die Zeile, in der OBJ definiert wird, wie folgt: 


OBJ^sre/Editor.o src/Speieher.o sre/Test.o 

Am Ende der Datei fügen wir noch folgende zwei Zeilen ein: 

src/Speicher.o: src/Speicher.c sre/Editor.h pre/Editor.pre 
sre/Test.o: src/Test.c sre/Editor.h pre/Editor.pre 

Die (wirklich) letzte Änderung, die wir machen sollten, besteht 
darin, die beiden Defines BIGBLCXTK und BLOCKSIZE auf 
kleinere Werte zu setzen, damit wir später nicht 10 KByte Text 
eingeben müssen, bevor wir einen zweiten Speicherblock erhal¬ 
ten. Wir ändern also 10 KByte in 120 Bytes und 5 KByte in 60 
Bytes um. Damit können wir auch gleich ausprobieren, was pas- 
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siert, wenn wir eine Zeile einfügen wollen, die länger als ein 
völlig leerer Block ist. 

Damit heißt es mal wieder compilieren und ausprobieren. Beim 
Einfügen einer Zeile, die größer als der Block ist, fällt auf, daß 
ein neuer Block beschafft wird, obwohl die Zeile dann auch dort 
nicht hineinpaßt. Da wir aber später die Blöckgröße wieder auf 
5 KBytes heraufsetzen und wir ja wohl kaum Zeilen eingeben 
werden, die auch nur annähernd an diese Größe herankommen, 
werden wir mal ein Auge zudröcken. Ebenfalls interessant ist 
folgender Effekt: wenn z.B. nur noch 22 Bytes in einem Block 
frei sind, so paßt dort entweder eine Zeile mit 21 oder 22 Zei¬ 
chen oder eine mit weniger als zehn Zeichen hinein, da dann 
auch noch Platz für eine Speicherstueck-Struktur geschaffen 
werden muß! 


4.3.5 Zeilen löschen 

Allerdings haben wir bisher nur die Funktionen zum Einfügen 
einer neuen Zeile getestet. Um die Funktionen optimiereBlock 
und garbageCollection testen zu können, müssen wir eine Funk¬ 
tion schreiben, die eine beliebige Zeile löschen kann. Diese 
Funktion entfernt zuerst die Zeile aus der Liste, sucht den 
Block, in dem diese liegt, und wandelt die Zeile anschließend in 
ein Speicherstück um. Abschließend wird noch der Block opti¬ 
miert. In C sieht das Ganze so aus: 

void loescheZeile (zeile) 
register struct Zeile *zeile; 

< 

register struct Speicherblock *blk,*fblk « NULL; 
register struct Speicherstueck *st; 

t* Zeile aus Liste entfernen: V 
RemoveCzeile); 

/* eventuelle Zeiger auf diese Zeile auf Null setzen: V 
if (aktuellerEditor*>aktuell » zeile) 
aktuellerEditor->aktuell « NULL; 
if (aktuellerEditor->top == zeile) 
aktuellerEditor->top = NULL; 
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i* Stelle fest, in welchem Block die Zeile liegt: */ 
for <blk = aktuellerEditor->block.head; blk->succ; 

blk = blk->succ) 
if ((Zeile > blk)&&( 2 eile < (((UBYTE *)(blk+1)) 

♦ blk->laenge))) 

C 

fblk = blk; 
break; 

> 

if (fblk) 

/* Zeile in Speicherstueck umwandeln, in Liste einfuegen: V 
fblk->frei •»■= ( ((struct Speicherstueck *) 2 ei le)->len 
- EVENLEN(zeile->len) ); 

AddTail(&(fblk'>freiliste),zeile); 

opt i mi ereB l ock( f bl k) ; 

if (fblk->laenge == (fblk->frei ♦ si 2 eof(struct 

Speicherstueck))) 

/* Block enthaelt keine Zeilen mehr: Loeschen! V 
freeSpeicherblock(fblk); 

> 

> 

Wenn die Zeile die letzte in dem Speicherblock war, so wird 
dieser daraufhin gelöscht. Bevor wir jetzt noch ein paar zusätz¬ 
liche Funktionen zum Testen schreiben, noch eine Bemerkung 
zur Funktion ConvertSpstToZeile: Weil es am einfachsten zu re¬ 
alisieren war, haben wir dort, falls die einzufügende Zeile klei¬ 
ner war als das Speicherstock, dieses so aufgeteilt, daß die Zeile 
ans Ende kam. Dies bedeutet, daß die Zeilen in einem Block von 
hinten nach vorne wachsen. 

Allerdings haben wir es bei der Garbage Collection genau an¬ 
dersherum gehalten, nämlich so, daß alle Zeilen an den Block¬ 
anfang kommen. Solche Unstimmigkeiten bemerkt man immer 
erst hinterher, aber es ist ja noch nicht zu spät. Aus diesem 
Grund ändern wir die Funktion ConvertSpstToZeile so, daß die 
Zeilen von vorne nach hinten wachsen: 

Struct Zeile *ConvertSpstToZeile(blk,st,len) 
struct Speicherblock ♦blk; 

regiSter struct Speicherstueck ♦st; 
regiSter UUORD len; 


register UUORD l; 
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register struct Zeile *z; 

z = (struct Zeile *)st; 

if (st->len == (l = EVENLEN(len))) 

/* Gefundenes Stueck passt genau: V 
ReiT)ove(st); 
eise 
i 

/* Stueck auftei len: */ 

((UBYTE *)st) += (l += sizeof (struct Zeile)); 

( st->succ = ((struct Speicherstueck *)z)->succ ) 

->pred = st; 

( st->pred = ((struct Speicherstueck *)z)->pred ) 

->succ = st; 

st->len = ((struct Speicherstueck *)z)->len • l; 

> 

blk->frei -= l; 

z->flags = 0; 
z->len = len; 

return (z); 

> 

Kleiner Nachteil dieser Problemlösung: Die Zeiger für die Ver¬ 
kettung müssen umgebogen werden. Dies gibt uns dafür aber 
wieder einmal Gelegenheit, mit den Möglichkeiten von C zu 
spielen. Der Assembler-Code, den die beiden Zeilen ergeben, die 
die Zeiger umbiegen, ist übrigens ziemlich optimal. Schauen Sie 
sich doch mal den Assembler-Code an. Dazu übersetzen Sie das 
Modul Speicher wie folgt: 

cc +B -»-Ipre/Editor.prc src/Speicher.c -a -t -o rain:sp.asm 

Der erzeugte Assembler-Code befindet sich dann unter dem 
Namen sp.asm auf der RAM-Disk. Da der Assembler-Code als 
Kommentare die C-Befehle enthält, ist es nicht allzu schwierig, 
die Stelle zu finden: Suchen Sie zuerst nach dem Label 
_ConvertSpstToZeile, dann gehen Sie mit dem Cursor solange 
nach unten, bis Sie als Kommentar die oben genannten Zeilen 
sehen. Direkt darunter sollte sich der Assembler-Code dieser 
Zeilen befinden. Bei uns sah diese Stelle wie folgt aus: 

; ( st->succ = ((struct Speicherstueck *)z)->succ )->pred = st; 

f 

move.l (a3),a0 ;a3 = z 

move.l a0,(a2) ;a2 » st; 
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move.l a2,4(a0) 

; ( st->pred = ((struct Speicherstueck *)z)->pred )->succ = st; 

# 

move.l 4(a3),a0 
move.l a0,4(a2) 
move.l a2,(a0) 

Daran läßt sich wirklich nichts mehr von Hand optimieren. 
Vielleicht schauen Sie sich bei der Gelegenheit auch gleich an, 
wie der Assembler-Code der anderen Funktionen aussieht. Dabei 
werden Sie nämlich bemerken, daß man durchaus noch etwas 
verbessern kann, z.B. bei folgendem Ausschnitt aus der Funktion 
garbageCollection, wobei ein Stück Speicher verschoben werden 
soll; 


; /* Zeile nach ptr herunterschieben: V 

; for (n = (EVENLEN(fz->len) + sizeof(struct Zeile)) » 1; 

; n; n--) 

move.l d5,a0 ;d5 = fz 

move.l #0,d0 ;d6 = n 

move.b 9(a0),d0 ;a2 = ptr 

add.w #1,d0 
bclr.l #0,d0 
add.w #10,dO 
move.w d0,d6 
Isr.w #1,d6 
bra .74 
.73 

; *((UWORD *)ptr)+-i- = ♦((DWORD *)fz)++; 

move.l d5,a0 
add.l #2,d5 
move.l a2,a1 
add.l #2,a2 
move.w (a0),(a1) 

.71 

sub.w #1,d6 
.74 

tst.w d6 
bne .73 
.72 


Hier kann man vor allem in der Schleife ab Label .73 einiges 
verbessern. So lassen sich die fünf Befehle direkt nach Label .73 
durch einen einzigen ersetzen (MOVE.W (An)+,(Am)+), wenn 
man die Variable fz in ein Adreßregister packt statt in ein Da¬ 
tenregister. Auch die drei Befehle nach Label .71 und .74 lassen 
sich durch einen DBRA-Befehl züsammenfassen. Wenn sich 
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diese Funktion im späteren Betrieb als zu langsam herausstellt, 
dann können wir unter anderem an dieser Stelle mit Verbesse¬ 
rungen ansetzen. 


Als nächstes brauchen wir noch Funktionen für unser Test-Mo¬ 
dul, mit denen wir Zeilen löschen können. Auch wäre es inter¬ 
essant zu wissen, wie der Speicher der einzelnen Speicherblöcke 
aufgeteilt ist. Sehen Sie sich dazu folgende Funktionen an: 


void print_speicher() 

< 

struct Speicherblock *blk; 

reg 1 Ster UBYTE *ptr,*end; 

register struct Zeile *z; 

register struct Speicherstueck *st; 

struct Zeile *fz; 

struct Speicherstueck *fst; 


print f("Speicheraufbau:\n"); 

for (blk = aktuellerEditor->block.head; blk->succ; 

blk = blk->succ) 


printf("\nBlock %8lx, Laenge = %ld. Frei = %ld\n'', 
blk,blk->laenge,blk->frei); 


ptr = (UBYTE *)(blk + 1); 
end = ptr + blk->laenge; 
while (ptr < end) 
i 

fz = NULL; 
fst = NULL; 


/* Suche Zeile, die am naechsten an ptr liegt: V 
for (z = aktuellerEditor->zeilen.head; 

z*>succ; z = z->succ) 
if ((z >= ptr) && (z < end)) 

if (z < ((fz)? fz : (struct Zeile *)end)) 
fz = z; 


/* Keine Zeile gefunden oder zeile > 

ptr -> suche Sp.stueck V 

if ((fz > ptr) jI !fz) 
i 


for (st = blk->freiliste.head; st->succ; st = st->succ) 
if ((st >= ptr) && (st < end)) 
if (st < ((fst)? fst : 

(struct Speicherstueck *)end)) 

fst = st; 


/♦ Falls Speicherstueck > ptr -> Fehler!!!!! V 
if ((fst > ptr) j j !fst) 
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pn'ntfC* Unbenutztes Speicherstueck! \n"); 
if (fz) 
if (fst) 

if (fst < fz) 

ptr = (UBYTE *)fst; 
eise 

ptr = (UBYTE *)fz; 

eise 

ptr = (UBYTE *)fz; 

eise 

if (fst) 

ptr = (UBYTE *)fst; 
eise 
break; 

> 

eise 

C 

/* Speicherstueck: V 

printf("Speicherstueck (%d)\n",fst->len); 

ptr += sizeof(struct Speicherstueck) + fst->len; 

> 

> 

eise 

C 

/* Zeile */ 

printfC'Zei le: XsXn'Sfz-t-l ); 

ptr += sizeof(struct Zeile) + EVENLEN(fz->len); 

> 

> 

> 

printf("\n"); 


void loesche_zei leO 
i 

register struct Zeile *z; 

UWORD nr; 

printf("Nummer der Zeile, die geloescht werden soll: C0..n] "); 
scanf("%d",&nr); 

while (getcharO != 10) ; /* CR einiesen! V 

for (z=aktuellerEditor->zeilen.head; z->succ && nr; z=z->succ,nr--) 

if (z->succ) 
i 

printf("Loesche: Xs\n",z+1); 
loescheZeile(z); 

> 

> 
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Die Funktion print_speicher sieht ja ziemlich wild aus, aber sie 
ist nur dafür zuständig, nacheinander jeden Block durchzugehen 
und die Zeilen und Speicherstücke in der Reihenfolge, in der sie 
im Block liegen, auszugeben. 

Lediglich, wenn die Funktion feststellt, daß der Block ein Stück 
Speicher enthält, das weder Zeile noch Speicherstueck ist, wird 
eine Fehlermeldung ausgegeben und versucht, den Fehler da¬ 
durch abzufangen, daß der Zeiger ptr auf den Anfang der 
nächstgelegenen Zeile oder des Speicherstücks gesetzt wird. Der 
Zeiger ptr zeigt dabei stets auf den Anfang des Speicherbereichs, 
der noch zu durchsuchen ist, und end auf das Ende desselben. 

Viel einfacher sieht da schon die zweite Funktion, loesche_zeile, 
aus! Diese verlangt nur nach der Eingabe einer Zahl und löscht 
dann die entsprechende Zeile, wobei wir von Null an aufwärts 
zählen. 

Die While-Schleife mit dem getchar muß leider sein, da sonst 
ein Zeilenende überbleibt, das dafür sorgt, daß wir in der 
Funktion Test erst nach erneutem Drücken der Return-Taste 
Eingaben vornehmen können. 

Es mag zwar elegantere Lösungen geben, aber schließlich han¬ 
delt es sich hier um ein Testprogramm, bei dem es nur auf 
Funktionalität ankommt, und die Testfunktionen werden im fer¬ 
tigen Programm ohnehin nicht mehr enthalten sein. 

Die Switch-Case-Anweisung der Funktion Test wird um fol¬ 
gende Zeilen bereichert, damit wir auch die neuen Testfunktio¬ 
nen ausprobieren können: 

case 's': 

print_speicher(); 
break; 
case 'd': 

loesche_zeile(); 

break; 


Und mit dem Ausprobieren können wir sofort anfangen. Über¬ 
setzen Sie das Programm, und probieren Sie die einzelnen Funk¬ 
tionen aus: Fügen Sie neue Zeilen an, löschen Sie andere, und 
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lassen Sie sich zwischendurch immer wieder mal die Speicherbe¬ 
legung anzeigen. Vielleicht finden Sie ja noch die eine oder an¬ 
dere Stelle, an der sich noch etwas verbessern läßt. Den kom¬ 
pletten Quelltext und den bereits compilierte Editor finden Sie 
auf der Diskette zum Buch, im Verzeichnis V0.2! 


4.3.6 Ausgeben von Text im Fenster 

Im folgenden werden wir einige Funktionen implementieren, die 
es uns ermöglichen, den Text im Editorfenster auszugeben und 
nicht wie bisher im CLI-Fenster. Wie in (fast) allen Bereichen, 
so bietet der Amiga bzw. sein Betriebssystem hier verschiedene 
Möglichkeiten, um zum Ziel zu gelangen. Wenden wir uns zuerst 
dem Fenster zu. Wenn Sie sich im Intuition-Teil dieses Buches 
die verschiedenen Möglichkeiten ansehen, die Sie beim Umgang 
mit Fenstern haben, so haben Sie die Qual der Wahl, welche Sie 
davon nutzen wollen. 

Das Fenster, mit dem wir bisher gearbeitet haben und mit dem 
wir auch in Zukunft arbeiten werden, ist ein "ganz normales" 
Fenster. Schauen wir uns dazu nochmals die Daten der NewWin- 
dow-Struktur aus unserem Hauptprogramm an; 

100,50,440,156, 

Dies ist die Startposition des Fensters. Diese werden wir aller¬ 
dings ändern (Bildschirm-föllend), sobald der Editor halbwegs 
funktioniert. 

AUTOFRONTPEN,AUTOBACKPEN, 

Diese Zeile sorgt dafür, daß unser Fenster dieselben Farben hat 
wie ein normales Workbench-Fenster. Als nächstes folgen die 
IDCMP-Flags: 

REFRESHWINDOU | NOUSEBUTTONS | RAWKEY | CLOSEUINDOU | NEUSIZE, 

Wir wollen also mitgeteilt bekommen, wenn der Inhalt des Fen¬ 
sters neu ausgegeben werden muß, wenn der Benutzer die Maus¬ 
oder Tastaturtasten gedrückt hat, wenn er das Schließfeld des 
Fensters angeklickt hat und wenn die Größe des Fensters verän- 
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dert wurde. Der letzte Punkt ist neu, auf ihn kommen wir noch 
zu sprechen. Als letztes wollen wir uns noch den Windowflags 
zuwenden: 

UINDOUSIZING j UINDOUDRAG | WINDOUDEPTH j WINDOUCLOSE | 

SIZEBBOTTOM | SIMPLE_REFRESH | ACTIVATE, 

Das Fenster soll sich also vergrößern, verkleinern, bewegen und 
nach vorne und hinten bringen lassen. Ferner wollen wir nicht 
auf das Schließfeld verzichten, sonst wäre das CLOSEWINDOW- 
Flag bei den IDCMP-Flags ja sinnlos. Das Feld zum Vergrößern 
und Verkleinern soll sich im unteren Rahmen des Fensters be¬ 
finden, so daß wir mehr Breite zur Verfügung haben. Das letzte 
Flag sorgt dafür, daß das Fenster beim öffnen gleichzeitig akti¬ 
viert wird, was bei einem Editor sinnvoll ist. 

Ein Flag, das wir wegen seiner Komplexität bis jetzt noch nicht 
besprochen haben, ist das SIMPLE_REFRESH-Flag. Dieses Flag 
bestimmt, was das Betriebssystem machen soll, wenn der Inhalt 
des Fensters zerstört wird, wenn also zum Beispiel ein anderes 
Fenster über unser Editorfenster gelegt wird. Hier gibt es ins¬ 
gesamt drei Alternativen, die im vorigen Kapitel bereits näher 
beleuchtet wurden, so daß Sie deren Vor- und Nachteile kennen. 
Sinnvoll für unser Programm ist nur SIMPLE_REFRESH oder 
SMART_REFRESH. Da unser Fenster aber ohnehin die meiste 
Zeit ganz vorne liegen und damit nicht verdeckt werden wird, 
reicht SIMPLE_REFRESH für unsere Zwecke aus, vor allem, da 
SIMPLE_REFRESH-Fenster weniger Speicher verbrauchen als 
SMARTREFRESH-Fenster. 

Einen Nachteil haben allerdings SIMPLE_REFRESH-Fenster, 
den wir aber erst in Erfahrung bringen können, wenn wir das 
Scrolling einbauen. Haben Sie schon mal in einem SIM- 
PLE_REFRESH-Fenster gescrollt, wenn ein anderes Fenster 
dieses teilweise verdeckt hat? (Vorausgesetzt, das Scrolling ge¬ 
schieht mittels der Graphics-Funktion ScrollRaster, also durch 
Verschieben des Fensterinhaltes.) Das Ergebnis sieht etwas selt¬ 
sam aus, da das Betriebssystem keine Informationen darüber hat, 
was in dem verdeckten Fensterteil liegt; aber wann scrollt man 
denn schon mal, wenn ein Teil des Fensters verdeckt ist? Wenn 
Sie dies stört, so können Sie SIMPLE_REFRESH auch durch 
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SMART_REFRESH ersetzen, was dann allerdings mehr Speicher 
belegt. 

Ein weiteres Problem tritt bei der Ausgabe von Texten in unse¬ 
rem Fenster auf. Es gilt dabei zu beachten, daß wir diese nicht 
in den Fensterrahmen schreiben. Allerdings gibt es auch zu die¬ 
sem Zweck ein Flag, nämlich das GIMMEZEROZERO-Flag. 
Dieses sorgt dafür, daß wir einen eigenen RastPort für die Aus¬ 
gabe innerhalb des Fensters bekommen, und daß der Fenster¬ 
rahmen (Border) in einem seperaten RastPort liegt, so daß wir 
diesen nicht zerstören können. Aber auch dies ist mit erhöhtem 
Speicherbedarf verbunden, und leider wird die Ausgabe auch 
noch langsamer, da ja nun zwei RastPorts von Intuition verwal¬ 
tet werden müssen. Wir werden daher auch hier den weniger 
einfachen, dafür aber effizienteren Weg gehen, und das soge¬ 
nannte Clipping selbst vornehmen, also dafür sorgen, daß unser 
Text nicht in die Fensterumrahmung hineinragt. 

Für das eigentliche Ausgeben des Textes gibt es wieder zwei 
Möglichkeiten bzw. Funktionen. Eine davon stammt aus der 
Graphics-Library und heißt Text, die zweite kommt von Intui¬ 
tion und nennt sich PrintIText. An die Graphics-Funktion Text 
übergeben Sie nur einen Zeiger auf den RastPort, den Text und 
dessen Länge, während PrintIText einen Zeiger auf den RastPort 
und einen auf eine IntuiText-Struktur, ferner noch X- und Y- 
Koordinaten braucht. In der IntuiText-Struktur können Sie 
Schreibmodus, Farbe, Position und den Zeichensatz festlegen, in 
dem der Text ausgegeben wird. Ferner muß der Text, auf den 
die IntuiText-Struktur zeigt, durch ein Null-Byte abgeschlossen 
sein. 

Auf den ersten Blick ist die Intuition-Funktion komfortabler zu 
handhaben, während sich die Graphics-Funktion dagegen eher 
ärmlich ausnimmt. Allerdings können Sie sich ausrechnen, daß 
der Komfort durch einen höheren Zeitbedarf erkauft wird. Sie 
wissen ja, daß man nichts umsonst bekommt! Welche "Sonder¬ 
funktionen" brauchen wir denn überhaupt für unseren Editor, 
was die Ausgabe von Texten angeht? Wir müssen die Ausgabe¬ 
position festlegen können (Move aus Graphics-Library). Con¬ 
trol-Codes wollten wir in Rot ausgeben, also müssen wir die 
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Farbe umschalten können (SetAPen aus Graphics-Library). Fer¬ 
ner haben wir uns überlegt, bestimmte Wörter (reservierte C- 
Wörter) in Fettdruck auszugeben (SetSoftStyle). Sonst brauchen 
wir eigentlich nichts, so daß die Intuition-Funktion fast schon 
unterfordert wäre. Wir wählen also zum dritten Mal die primiti¬ 
vere Funktion, aber nicht, weil wir die komfortablen Funktionen 
des Betriebssystems nicht zu schätzen wüßten, sondern weil diese 
für unsere Anwendung geeigneter (schneller) sind. 

Wie sorgen wir nun dafür, daß unser Text nicht doch den Fen¬ 
sterrahmen überschreibt? Ganz einfach: Wir bestimmen, wie 
viele Zeichen unser Fenster bzw. der Innenraum unseres Fensters 
(das Fenster ohne Rahmen also) breit und hoch ist. 

Dann brauchen wir bei der Ausgabe nur noch darauf zu achten, 
daß wir nicht mehr Zeichen ausgeben. Breite und Höhe des 
Fensters legen wir in der Editor-Struktur ab, da diese Werte bei 
mehreren Fenstern verschieden sein können. 

Da sich diese beiden Werte aber ändern, wenn die Größe des 
Fensters verändert wird, müssen wir davon in Kenntnis gesetzt 
werden. Dies geschieht über das NEWSIZE-Flag, das wir neu in 
unsere IDCMP-Flags aufgenommen hatten. Jedesmal, wenn wir 
eine entsprechende Nachricht erhalten, berechnen wir die Fen¬ 
sterbreite und -höhe neu. Da wir ein SIMPLE_REFRESH-Fen- 
ster haben, bekommen wir direkt danach auch noch eine RE- 
FRESHWINDOW-Nachricht und können den Inhalt des Fensters 
gleich neu ausgeben. 

Nun bleiben aber rechts und unten zwei Ränder, die weder zum 
Fensterrahmen noch zum Text gehören. Diese entstehen dadurch, 
daß die Breite des Fensters nicht zwingendermaßen durch die 
Breite der Buchstaben teilbar ist. Gleiches gilt analog für die 
Höhe. Was machen wir nun mit dem Rand, der in der folgenden 
Zeichnung hell gepunktet ist, wärend der Fensterrahmen dunkel 
gehalten ist: 
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xoff xrl xrr 

Abbildung 4,1: Window-Beispiel 


Die Buchstaben wurden dabei überproportional groß dargestellt, 
damit auch die Ränder größer werden und damit besser erkenn¬ 
bar sind. Über dem Fenster sehen Sie einen Buchstaben, an dem 
exemplarisch dessen Breite (cw = CharacterWidth) und Höhe (ch 
= CharacterHeight) angezeichnet ist. Da wir glücklicherweise 
keinen proportionalen Zeichensatz verwenden, sind diese Werte 
für alle Buchstaben gleich. Die Breite des Fensters in Zeichen 
(wcw = WindowCharacterWidth) erhalten wir, indem wir die 
tatsächliche Breite des Fensters nehmen (window->Width), die 
Breite des linken (window->BorderLeft) und rechten Fenster¬ 
rahmens (window->BorderRight) abziehen und das Ergebnis 
durch die Breite eines Buchstabens (cw) dividieren. Für die 
Höhe gehen wir analog vor: 

weh = (wirKiow’>Height - window*>BorderTop 

- window->BorderBottom) / ch; 
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Für die Ausgabe brauchen wir ebenfalls die Breite des linken 
und des oberen Fensterrahmens, da diese beiden die oberste 
linke Position unseres Fensters beschreiben. Die beiden Werte 
speichern wir als xoff (X-Offset) und yoff (Y-Offset) in unsere 
Editor-Struktur ab, ebenso wie cw und ch, die durchaus für 
verschiedene Fenster unterschiedlich ausfallen können, wenn 
man mittels Preferences den Zeichensatz ändert und danach ein 
weiteres Editorfenster öffnet! Auch in unsere Editor-Struktur 
gehört ein Zeiger auf den RastPort des dazugehörigen Fensters, 
damit wir nicht immer über die Window-Struktur gehen müssen, 
um an diesen heranzukommen. Sie wissen ja, daß auf dem 
Amiga grafische Ausgaben nur über RastPorts laufen. 

Unsere Frage, was wir mit den Rändern machen, haben wir aber 
immer noch nicht beantwortet. Wir brauchen diese zwar nicht, 
aber störenden "Grafikmüll" sollten diese auch nicht enthalten. 
Daher löschen wir sicherheitshalber den Inhalt der beiden Rän¬ 
der jedesmal, wenn wir eine REFRESHWINDOW-Nachricht er¬ 
halten. Dazu benötigen wir zusätzliche Informationen, wie zum 
Beispiel die Position der Ränder. In der obigen Zeichnung sind 
die außer xoff und yoff zusätzlichen Koordinaten mit xrl (X, 
Rand, linke Ecke), xrr (X, Rand, rechte Ecke) und yru (Y, 
Rand, untere Ecke) bezeichnet. Zusätzlich benötigen wir die 
obere Ecke des Randes, die in der Zeichnung mit Y angegeben 
ist. Dieses Y brauchen wir aber jetzt noch nicht zu berechnen, 
da es sich quasi von selbst ergibt Wir werden nämlich den Text 
Zeile für Zeile ausgeben und dabei die Y-Koordinate herauf¬ 
zählen. Wenn entweder das Fenster voll oder kein Text mehr da 
ist, haben wir die Y-Koordinate der Zeile direkt unter der letz¬ 
ten Textzeile, die exakt der oberen Ecke des Randes entspricht. 

Weitere Einzelheiten ergeben sich im Programm. Beim Positio¬ 
nieren des Textes gilt es aber zu beachten, daß der Text immer 
relativ zu seiner Baseline ausgegeben wird. Wir müssen daher die 
Y-Position um den Abstand der Baseline von der oberen Kante 
des Buchstabens erhöhen, bevor wir Move auf rufen. Doch genug 
der Feinheiten! Bauen wir jetzt die einzelnen Funktionen zu¬ 
sammen, die für die Ausgabe des Textes sorgen: 


void pn'ntAUO 
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Diese Funktion gibt den gesamten Text aus. Dabei wird zunächst 
die oberste Zeile im Fenster bestimmt, ab dieser werden solange 
Zeilen ausgegeben, bis das Fenster voll oder das Textende er¬ 
reicht ist. Dabei wird die Funktion printLine auf gerufen, an die 
ein Zeiger auf die Zeile und die aktuelle Y-Position übergeben 
wird. Danach werden die beiden Ränder gelöscht, sofern diese 
breiter (höher) als null sind. Die nächste Funktion ist damit lo¬ 
gischerweise: 

void printLine(zeUe,y) 

Diese gibt die Zeile linksbündig an der übergebenen Y-Position 
aus. Doch dies ist gar nicht so einfach, wie es sich zunächst an- 
hört! So arbeitet unser Editor mit "richtigen" Tabulatoren, die 
bei der Ausgabe nur als Kästchen erscheinen würden. Wenn wir 
die Ausgabe über das Console.Device laufen lassen würden, so 
würden Tabulatoren richtig ausgegeben werden. Allerdings hat 
das Console.Device viel zu viel Overhead, mit dem wir nichts 
anfangen könnten und der die Ausgabe langsamer macht. Also 
müssen wir die Tabulatoren selbst umwandeln. Dazu verwenden 
wir eine weitere Funktion: 

void convertLineForPrintttext,länge,breite,puffer) 

Diese erwartet einen Zeiger auf den Text (und nicht mehr auf 
die Zeile-Struktur) und dessen Länge. Ferner müssen Sie einen 
Zeiger auf einen Puffer übergeben, in den die konvertierte Zeile 
geschrieben wird, sowie die Breite einer Zeile, da alles bis zum 
Zeilenende ggf. mit Blanks aufgefüllt wird. Da das CR bzw. LF 
am Ende einer Zeile aus optischen Gründen nicht mit ausgege¬ 
ben werden sollte, wird es von dieser Funktion abgeschnitten. 
Wird die Zeile nicht durch ein CR, LF oder CRLF beendet, so 
wird der Rest der Zeile mit Punkten (CHR$(183)) auf gefüllt, 
was bedeuten soll, daß die Zeile noch weitergeht. Dieses gilt 
auch für Zeilen, die nicht ganz in das Fenster passen, also zu 
lang sind. So bedeutet ein Punkt (CHR$(183)) am Ende einer 
Zeile immer, daß die Zeile noch weitergeht, mehrere Punkte, 
daß die Zeile nicht durch ein normales Zeilenende abgeschlossen 
ist. 
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Bei der Ausgabe der konvertierten Zeile könnten wir es uns nun 
einfach machen und diese einfach mittels der Graphics-Funktion 
Text ausgeben. Da aber eine Zeile stets auch aus Blanks besteht, 
sei es, weil die Zeile nicht so breit wie das Fenster ist, sei es, 
daß die Zeile aus Formatgränden eingerückt ist, wäre dies un¬ 
effizient. Das Ausgeben von Blanks kostet genausoviel Zeit wie 
das Ausgeben eines Buchstabens. Schneller ist es, wenn wir hin¬ 
tereinander liegende Blanks auf den Bildschirm bringen, indem 
wir einfach ein Rechteck zeichnen, das dieselbe Größe hat. 
Diese Aufgabe nimmt uns die folgende Funktion ab: 

void printAt(puffer,länge,x,y) 

Außerdem behandelt diese Funktion auch die Ausgabe von 
Control-Codes, die in Rot ausgegeben werden, also CHR$(1) als 
rotes "A" ("A" = CHR$(1 | 64)). Obergeben wird ein Zeiger auf 
den Text, dessen Länge, die normalerweise der Bildschirmbreite 
in Zeichen entspricht, und die Position, wobei die X-Koordinate 
in der Regel xoff entspricht. Damit haben wir nun die wesent¬ 
lichen Funktionen zur Ausgabe des Textes auf dem Bildschirm 
zusammen. Fehlt nur noch eine Funktion, die die ganzen Werte 
bestimmt, von denen die Ausgabe abhängt, also wcw, weh, xoff 
etc.: 


void initUindowSize(ed) 

Die Variable ed zeigt dabei auf die Editor-Struktur, deren Werte 
bestimmt werden sollen. Lassen Sie uns, bevor wir an die Reali¬ 
sierung der Funktionen gehen, nochmals unsere Liste mit den 
Eigenschaften durchgehen, die unser Editor haben soll. Viel¬ 
leicht finden wir ja etwas, das wir bereits jetzt berücksichtigen 
sollten, damit wir später weniger Arbeit damit haben. Folding! 
Wenn wir Folding in den Editor einbauen, so liegen zwei Zeilen, 
die im Fenster direkt untereinander stehen, im tatsächlichen 
Text vielleicht einige Zeilen auseinander; man kann ja beliebig 
viel Text "wegfalten". Das bedeutet aber, daß es nicht reicht, uns 
nur einen Zeiger auf die oberste Zeile zu merken (Editor- 
Struktur: top), wie wir es bisher vorgesehen hatten. Wenn wir 
dann nämlich auf eine Zeile zugreifen wollen, so müßten wir 
uns schlimmstenfalls durch ein paar hundert Zeilen durchkämp¬ 
fen, bis wir die Zeile erreicht haben, die wir suchen. 
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Schneller geht es, wenn wir uns für jede Zeile, die im Fenster 
sichtbar ist, und am besten für die nächste Zeile auch noch, 
einen Zeiger darauf merken. Wenn wir die Position im Fenster 
kennen, dann kommen wir direkt an den Zeiger und über den 
Zeiger sofort zur Zeile. Nachteil: Wir müssen stets die Zeiger 
aktualisieren. Dies kostet aber weniger Zeit als das Durchhangeln 
durch die Liste. Da die maximale Anzahl der Zeilen, die auf den 
Bildschirm passen, beschränkt ist, und zwar auf 64 (gleich S12 
(maximale Auflösung) durch 8 (Höhe eines Zeichens)), können 
wir auch das Feld auf diese Größe festlegen. Dabei werden al¬ 
lerdings nur die Zeiger vermerkt, deren Zeilen auch wirklich 
auf dem Bildschirm zu sehen sind (plus die erste Zeile, die nicht 
mehr zu sehen ist), und nicht alle 64, es sei denn, das Fenster ist 
wirklich 63 Zeilen hoch; alle anderen setzen wir sicherheitshal¬ 
ber auf Null. 

Als erstes wollen wir die Include-Datei Editor.h entsprechend 
erweitern: 

Mefine MAXHOEHe 64 
«define FGPEN 1L 
#def1ne BGPEN OL 
#define CTRLPEN 3L 

#define CONTROLCaOE(c) (((c)&127)<32) 

struct Editor 

< 

struct Editor *succ; 
struct Editor *pred; 
struct Window *window; 
struct BList block; 
struct ZList Zeilen; 

UBYTE puffer[MAXBRE1TE]; 

UBYTE tabstring[MAXBREITE]; 

UUORD anz_zeilen; 

struct Zeile ^aktuell; 

struct Zeile *zeilenptr[MAXHOEHE]; 

UWORD toppos; 

UWORD xpos,ypos; 

UUORD changed:1; 

UUORD insert:1; 
struct RastPort *rp; 

UUORD xoff.yoff; 

UUORD cw,ch; 

UUORD wcw.wch; 

UUORD xrl,xrr,yru,bl; 

>; 
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Außer der maximalen Fensterhöhe werden auch noch die Stan¬ 
dard-Vordergrundfarbe (FGPEN = ForegroundPen), die Hinter¬ 
grundfarbe (BGPEN BackgroundPen) und die Farbe für die 
Control-Codes (CTRLPEN) definiert. Es wird ebenfalls festge¬ 
legt, was überhaupt ein Control-Code ist (CONTROLCODE), 
nämlich ein Zeichen, dessen Code kleiner als 32 oder größer¬ 
gleich 128 und kleiner als 160 ist. Dies sind die Zeichen, die im 
Amiga-Zeichensatz nur durch Rechtecke dargestellt werden. 
Wenn Sie Ihren eigenen Zeichensatz verwenden wollen, in dem 
Sie diesen Zeichen eigene Darstellungen zugewiesen haben, so 
können Sie die Definition von CONTROLCODE ja entsprechend 
ändern. 

Geändert wurde die Editor-Struktur Statt des Zeigers top ist 
dort nun das Feld zeilenptr vorhanden, wobei zeilenptrtO] die¬ 
selbe Funktion hat, die zuvor top zugedacht war. Des weiteren 
wurden zusätzliche Elemente für die Ausgabe am Ende der 
Struktur hinzugefügt, die aber schon besprochen wurden. Ent¬ 
sprechend müssen auch zwei Funktionen des Moduls Speicher 
umgeschrieben werden, die auf top Bezug nehmen. In der Funk¬ 
tion garbageCollection müssen die Zeilen: 

if (aktueUerEditor*>top == z) 
aktueUerEditor*>top = fz; 

durch die folgenden Zeilen ersetzt werden: 

for <n = 0, zptr = aktueUerEditor‘>zei lenptr; 
n <= aktuellerEditor~>wch; ry»-+, zptr-»--«') 
if <*zptr == z) 
i 

*zptr = fz; 
break; 

> 

wobei zptr noch als "struct Zeile ••zptr" definiert werden muß. 
Auch in der Funktion loescheZeile ist eine Änderung notwendig. 
Dort müssen die Zeilen: 

if (aktuellerEclitor->top ** zeile) 
aktueUerEditor->top - NULL; 


durch folgende ersetzt werden: 
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for (n = 0, zptr = aktueUerEditor-> 2 ei lenptr; 
n <= aktueUerEditor->wch; zptr++) 
if (*zptr == Zeile) 
i 

♦zptr = NULL; 
break; 

> 

Auch hier müssen zptr und n (UWORD) definiert werden. 
Kommen wir nun zu den Änderungen im Hauptmodul. Als ex¬ 
terne Funktion kommt nicht nur printAll hinzu; 

void initWindowSize(),SetDrMdt >,SetAPent),SetBPent), pri ntA11<); 
void BeginRefresh(),EndRefre8h(); 

Die beiden folgenden neuen Funktionen bestimmen jeweils die 
auf eine Zeile folgende bzw. die vorige Zeile. Im Moment sieht 
dies zwar noch etwas überflüssig aus, aber spätestens, wenn der 
Editor Folding beherrschen wird, werden Sie diese Funktionen 
zu schätzen wissen, da sie das "Durchhangeln" durch den Text 
vereinfachen: 


^********************************************* 

* 

* nextLineCZeile) 

* 

♦ Liefert Zeiger auf naechste Zeile zurueck, 

♦ (und beruecksichtigt dabei Folding!) 

♦ Null, falls keine naechste Zeile. 

♦ 

* Zeile “ Zeile-Struktur. 

* 

*********************************************^ 


struct Zeile *nextLine(zeile) 
register struct Zeile *zeile; 
C 

register struct Zeile ^z; 

if (Zeile) 

C 

if (z = zeile->succ) 
if (i(z->succ)) 
z = NULL; 

return (z); 

> 

eise 

return (NULL); 

> 
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y******************************************* 

♦ 

* prevLine(zeile) 

* 

* Liefert Zeiger auf vorige Zeile zurueck, 

* (und beruecksichtigt dabei Folding!) 

* Null, falls keine vorige Zeile. 

* 

* Zeile “ Zeile-Struktur. 

* 


*******************************************^ 


struct Zeile *prevLine(zeile) 
register struct Zeile *zeile; 
C 

register struct Zeile *z; 

if (Zeile) 
i 

if (z = zeile->pred) 
if (!(z->pred)) 
z = NULL; 

return (z); 

> 

eise 

return (NULL); 


Die Funktion OpenEditor wurde wesentlich erweitert: 

Struct Editor *OpenEditor() 
i 

register struct Editor *ed = NULL; 
register struct Window *wd; 
register struct RastPort ♦rp; 
register ULONG flags; 
register UBYTE *ptr; 
register struct Zeile **zptr; 
register DWORD n; 

/* IDCMPFlags retten, in Struktur auf NULL setzen! 

=> eigenen UserPort verwenden! V 
flags s newEdWindow.IDCMPFlags; 
newEdWindow.IDCMPFlags = NULL; 

/* Speicher fuer Editor-Struktur beschaffen: V 
if (ed = malloc(sizeof(struct Editor))) 

/* Fenster oeffnen: */ 

if (wd = OpenWindow(&newEdWindow)) 

i 


ed->window = wd, 
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ed->rp = (rp = wd->RPort); 

/* Schreibmodi setzen: V 
SetDrHd(rp,JAM2); 

SetAPenC rp,FGPEN); 

SetBPen(rp,BGPEN); 

/* UserPort einrichten: V 
wd->UserPort = edUserPort; 

ModifyIDCMP(wd,flags); 

/* Parameter initialisieren: V 
NewList(&(ed->block)); 

NewList(&(ed'>zeilen)); 
ed->anz_zeilen = 0; 
ed*>aktuell - NULL; 
ed->toppos = 0; 
ed->xpos = 1; 
ed->ypos =1; 
ed‘>changed = 0; 
ed->insert =1; 

/* zeilenptr-Array initialisieren: */ 
for (n = 0, zptr = ed->zeilenptr; 

n < MAXHOEHE; n++, zptr++) 

♦zptr = NULL; 

/* Tabulatoren initialisieren: V 
ptr = ed->tabstring; 

♦ptr++ = 1; 

for (n = 1; n < MAXBREITE; n+-»-) 
if (n X 3) 

♦ptr+-»- = 1; 
eise 

♦ptr++ = 0; 

ed->wch = 0; 
i ni tWi ndowS i ze( ed) ; 

> 

eise 

L 

free(ed); 
ed = NULL; 


neuEdWindow.IDCHPFlags = flags; 
return <ed); 


Das Initialisieren der Tabulatoren geschieht, damit wir auf jeden 
Fall ein paar definierte Tabulatoren zur Verfügung haben. In der 
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Abfrage des Nachrichtentyps im Hauptprogramm fügen wir zwei 
weitere Flags hinzu: 


case NEUSIZE: 

initWindowSize(aktuellerEditor); 

printO; 

break; 

case REFRESHUINDOW: 

BeginRefresh( aktue UerEditor->winck>«); 
printAlU); 

EndRefresh(aktueUerEditor’>uindow,TRUE); 

break; 

Die beiden Funktionen BeginRefresh und EndRefresh sollte man 
nach einem REFRESHWINDOW-Event auf jeden Fall aufrufen, 
damit Intuition weiß, daß das Fenster restauriert wurde. Außer¬ 
dem sorgen diese Funktionen dafür, daß nur die Teile des Fen¬ 
sters neu ausgegeben werden, die es nötig haben, aber das wis¬ 
sen Sie ja bereits aus dem zweiten Kapitel. Die Funktion print 
stammt aus der Testumgebung und wird noch etwas abgewandelt 
werden. Bevor wir uns dieser zuwenden, wollen wir das neue 
Modul "Ausgabe" implementieren: 


<src/Ausgabe.c> 

^w*********** 

* 

* Includes: 

* 

************ j 


#include <exec/types.h> 

# 1 nclüde <intui1 1 on/ 1 ntui1 1 on.h> 
#include ”src/Editor.h” 


^*********** 

* 

* Defines: 

* 

*********** j 


#define CR 13 
#define LF 10 
#define TAB 9 
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^***«r****************** 

* 

* Externe Funktionen: 

* 

********************** j 

void SetAPen(),RectFiU(),Text(),Move(); 
struct Zeile *nextLine(); 

y********************* 

* 

* Externe Variablen: 

* 

********************* y 

extern struct Editor *aktuellerEditor; 


* Funktionen: * 

* * 

*************** y 


y********************************** 

* 

* initWindowSize(ed) 

* 


* Initialisiert die Breite/Hoehe- 

* Angaben des aktuellen Fensters. 

* Ferner wird das zeilenptr-Feld 

* restauriert. 


* ed * Editor-Struktur. 

* 


**********************************y 


void initWindowSize (ed) 
regiSter struct Editor *ed; 

C 

register struct*Window *w; 
register struct RastPort *rp; 
register struct Zeile *z,**zptr; 
register DWORD'n,newh; 

w = ed->window; 
rp = ed->rp; 

ed->xoff = (UWORD)w->BorderLeft; 
ed->yoff = (DWORD)w->BorderTop; 

ed->cw * (rp->TxWidth)? rp->TxWidth : 8; 
ed->ch = (rp->TxHeight)? rp->TxHeight : 8; 

ed->wcw = (w->Width - ed->xoff - w->BorderRight) / ed->cw; 
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newh = (w->Height- ed->yoff - w->BorderBottom)/ ed->ch; 

ed->xrl = ed->xoff ed->wcw’*'ed->cw; 
ed->xrr = w->Width - W'>BorclerRight - 1; 
ed->yru = W’>Height - w->BorderBottom - 1; 
ed->bl = rp->TxBaseline; 

/* Nun ggf zeilenptr-Feld restaurieren: V 
if (newh != ed*>wch) 
i 

if (newh < ed’>wch) 
i 

/* Ueberfluessige Zeiger auf Null setzen: V 
zptr = ed->zei lenptr newh + 1; 
for (n = newh; n < ed->wch; n^-«-) 

♦zptr++ = NULL; 

> 

eise 

< 

zptr = ed->zeilenptr + ed->wch; 
z = *zptr++; 

for (n = ed->wch; n < newh; n+**-) 

*zptr+-»- = (z = nextLine(z)); 

> 

ed->wch * newh; 

> 

> 

y**************************************** 

* 

* convertLineForPrint(zeile,len,buf) 

* 

* Konvertiert zeile so, dass diese 

* einfach ausgegeben werden kann. 

* Dabei werden v.a. Tabs in Spaces 

* umgewandelt. 

* 

* zeile * Zeile. 

* len = deren Laenge. 

* w = maximale Breite. 

* buf * Puffer, in den die konvertierte 

* Zeile abgelegt wird. 

* 

****************************************^ 

void convertLineForPrint(zeile,len,w,buf) 

UBYTE *zeile; 

register WORD len; 

regiSter UWORD w; 

register UBYTE ♦buf; 

i 

register UBYTE *tab; 
register UWORD 1-1; 
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register UBYTE lastchar; 

/* Feststeller!, ob mit CR oder LF beendet: V 
if (len) 

< 

tab = Zeile + len - 1; 
if (*tab == CR) 
i 

len--; 

lastchar = * *; 

> 

eise if (*tab == LF) 

< 

len--; 

lastchar = * *; 
if (den) && (*--tab == CR)) 
len--; 

> 

eise 

lastchar = 183; 

> 

eise 

lastchar = 183; 

/* Zeile konvertieren: V 

tab = aktuellerEditor->tabstring; 

while (den--) && (I < w)) 

if ((*buf * *zeile++) *= TAB) 

i 

*buf++ = * *; 

l*+; 

tab++; 

> while ((*tab) && (I < w)); 
else 
i 

buf++; 

tab*-»-; 

> 

/* Feststellen, ob Zeile nicht komplett konvertiert: V 
if (len >= 0) 
lastchar » 183; 

/* Zeile bis zum Ende mit lastchar auffuellen: */ 
while (1++ <= w) 

*buf++ = lastchar; 



* 


* printAt(buf,len,x,y) 
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* Gibt Zeichenkette buf an Position 

* (x/y) im Fenster aus. Die Zeichen- 

* kette wird dabei veraendert! 

* 


* buf " Zeichenkette. 

* len = deren Laenge. 

* X = Pixel-X-Position. 

* y = Pixel-Y-Position. 

* 


***4r**4r*4r4r4r*********4r***4r*4r***4r***ilr* y 


void printAt (buf,len,x,y) 

regiSter UBYTE *buf; 

WORD len; 

register UWORO x,y; 

C 

struct RastPort *rp = aktueUerEditor->rp; 
register DWORD cw s aktuellerEditor‘>cw; 
register DWORD x2; 

DWORD y2 = y + aktuellerEditor*>ch - 1; 
DBYTE ♦ptr; 

DLONG l; 


while (len > 0) 
if (*buf == ' •) 
i 

/* Blanks ausgeben: */ 
x2 = X - 1; 

while ((*buf == • *) && len--) 
i 

buf-»-+; 
x2 += cw; 

> 

SetAPen(rp,BGPEN); 

RectFill(rp,(DLONG)x,(DLONG)y,(DLONG)x2,(DLONG)y2); 

SetAPen(rp,FGPEN); 

X = ++x2; 

> 

eise 

i 

/* Also Text ausgeben: V 

Move(rp,(DLONG)x,(DLONG)y aktuellerEditor->bl); 
ptr = buf; 

if (CONTROLCODE(*buf)) 

C 

SetAPen(rp,CTRLPEN); 

while (CONTROLCODE(*buf) && len--) 

*buf++ 1= 64; 
l = buf - ptr; 
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Text(rp,ptr,l); 

SetAPen(rp,FGPEN); 

> 

eise 

< 

while (!CONTROLCOOE(*buf) && (*buf != • *) 

&& len--) buf++; 

l = buf - ptr; 

Text(rp,ptr,l); 

> 

X += cw^l; 

> 

> 


* 

* printLine( 2 eile,y) 

* 

* Gibt Zeile auf dem Bildschirm an 

* Pixel-Position y aus. 

* 


* Zeile “ Zeile-Struktur. 

* y » Pixel-Position. 


************************************^ 


void Printline (zeile,y) 

register struct Zeile ♦zeile; 
regiSter DWORD y; 

< 

static UBYTE buf[MAXBREITE]; 
register DWORD u; 

convertLineForPrint<zeile+1,zeile->len,w = 

aktuellerEditor->wcw,buf); 
printAt(buf,w,aktuellerEditor->xoff,y); 

> 

* 

* printAll 

* 

* Gibt ganzen Bildschirm neu aus. 

* 

********************************** g 


void printAllO 

< 

register DWORD y,ch,count; 
register struct Zeile **z; 
register struct RastPort *rp; 

y a aktuellerEditor->yoff; 
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ch = aktuellerEd1tor->ch; 
count = aktuellerEditor->uch; 

rp = aktuellerEditor->rp; 

/* Zeilen ausgeben: V 

for (z = aktuellerEditor->zeilenptr; count-- SA (*z != NULL); 

Z++, y += ch) 

printLine(*z,y); 

/* Raender rechts und unten loeschen: V 

SetAPen(rp,BGPEN); 

if (aktuellerEditor->yru >= y) 

RectFilKrp, (ULONG)aktuellerEditor->xoff,(ULONG)y, 

(ULONG)aktuellerEditor->xrr, 

(ULONG)aktuellerEditor->yru); 
if ((aktuellerEditor->xrr >- aktuellerEditor->xrl) 

&& (y > aktuellerEditor->yoff)) 

RectFill(rp,(ULONG)aktuellerEditor->xrl, 

(ULONG)aktuellerEditor->yoff, 

(ULONG)aktuellerEditor->xrr,(ULONG)y-1); 

SetAPen(rp,FGPEN); 

) 

Auch hier wieder einige Bemerkungen zu den obigen Funktio¬ 
nen und deren Besonderheiten: 

In der Funktion initWindowSize wird bei der Größe des 
Zeichensatzes eine Sicherheitsabfrage auf Null gemacht. 
Dies kann zwar eigentlich nicht auftreten, aber da später 
durch diese Werte dividiert wird, sollte man sich den Lu¬ 
xus einer Abfrage gönnen, man weiß ja nie... 

Je nachdem, ob das Fenster vergrößert oder verkleinert 
wurde, werden zusätzliche Zeiger berechnet bzw. die 
überflüssigen Zeiger auf Null gesetzt. Dabei wird die 
Funktion nextLine verwendet, damit wir es um so einfa¬ 
cher haben, wenn wir Folding implementieren. Dann 
brauchen wir nur die Funktionen nextLine und prevLine 
zu ändern, und alle weiteren Funktionen, die auf diese 
beiden Funktionen zugreifen, funktionieren ebenfalls mit 
Folding. 

In convertLineForPrint wird zuerst das Zeilenende begut¬ 
achtet und dementsprechend die Variable lastchar gesetzt. 
Sie enthält das Zeichen, mit dem der Rest der Zeile auf¬ 
gefüllt wird. Die Variable tab dient dabei als Zeiger auf 
das Zeilenende. Beachten Sie dabei, daß hinter dem ei- 
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gentlichen Text der Zeile mindestens ein weiteres Zeichen 
ausgegeben wird, nämlich ein Blank oder ein Punkt. Wenn 
das Fenster also 70 Zeichen breit ist und die Zeile ebenso, 
so werden trotzdem nur 69 Zeichen angezeigt. In die sieb¬ 
zigste Spalte kommt dann der Punkt, da die Zeile ja nicht 
komplett ins Fenster paßte. 

In printAt enthalten x2 und y2 jeweils die Koordinaten 
der rechten unteren Ecke für das Rechteck, das im Falle 
von Blanks ausgegeben werden muß. Dabei muß zuvor die 
Zeichenfarbe auf die Hintergrundfarbe gesetzt werden, da 
wir sonst ein weißes Rechteck erhalten. 

Beim Move-Befehl wird die Baseline des Zeichensatzes auf 
die Y-Koordinate addiert, damit der Text richtig positio¬ 
niert wird. Die X-Koordinate wird jeweils auf die nächste 
Ausgabeposition gesetzt. 

Die vielen Typumwandlungen sind notwenig, da wir stets 
LONG-Werte an die Betriebssystemfunktionen übergeben 
müssen, sonst aber nach Möglichkeit mit Wörtern rechnen, 
da deren Bearbeitung schneller vonstatten geht. 

In der Funktion printLine definieren wir den Puffer als 
static, da er sonst unnötigerweise Platz auf dem Stack be¬ 
legen würde. Zwar belegen auch andere lokale Variablen 
Platz auf dem Stack, aber nicht 80 Bytes auf einmal. 

Haben Sie die Funktion RectFill schon mal mit Koordina¬ 
ten aufgerufen, bei denen die linke Ecke rechts von der 
rechten Ecke lag bzw. die obere Ecke unter der unteren 
Ecke? Damit können Sie Ihren Amiga schnell, sicher und 
bunt "abschießen", weswegen die Abfrage in printAll sehr 
wichtig ist. Wegen der Definition von xrl, xrr und yru 
kann es nämlich Vorkommen, daß die Ränder negative 
Breiten haben, nämlich genau dann, wenn die Breite bzw. 
Höhe des Fensters ganzzahlig durch die Breite bzw. Höhe 
eines Zeichens teilbar ist. In diesem Fall darf kein Rand 
ausgegeben werden! 

So weit, so gut. Fehlen nur noch die Änderungen in der Testum¬ 
gebung. Zuerst deklarieren wir ein paar externe Funktionen: 
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struct Zeile *nextLine<); 
void printAlU); 

Dann schreiben wir die Funktion print so um, daß sie uns die 
Werte der Zeiger liefert, die in dem Feld zeilenptr festgehalten 
werden: 

void printO 
< 

register struct Zeile **z; 
regiSter DWORD n; 

for (n = 0, z = aktuellerEditor‘>zeilenptr; 
n <= aktuel lerEditor->wch; z++) 
printfC'Zei le %d an Adresse X6lx.\n**,n,*z); 

> 

Neu hinzu kommt eine Funktion zur Initialisierung des zei- 
lenptr-Feldes. Diese werden wir so später nicht im eigentlichen 
Programm brauchen, so daß wir sie in die Testumgebung ausge¬ 
lagert haben: 

void init zeilenptrO 
i 

register struct Zeile *z,**zptr; 
register DWORD n; 

for (n = 0, z = (struct Zeile *) 

&(aktuellerEditor*>zeilen.head), 
zptr = aktuel lerEditor->zei lenptr; n < MAXHOEHE; rr»-+) 

♦zptr-»"»- = <z = nextLine(z)); 

> 

Und zu allerletzt ändern wir noch etwas im eigentlichen Test¬ 
programm. Nach dem Einfügen und Löschen von Zeilen muß 
jetzt das zeilenptr-Feld neu initialisiert werden. Ferner muß bei 
dem Befehl p (print) auch die Funktion print All auf gerufen 
werden. Die entsprechenden Zweige der Switch-Case-Anweisung 
sehen nun so aus: 

case 'a*: 
inputO; 

init^zei lenptrO; 
break; 
case 'p': 
printO; 
printAllO; 



590 


Das große C-Buch zum Amiga 


break; 
case ’d': 

loesche_zeile(); 

init_zeTlenptr(); 

break; 

Nachdem Sie die Make-Datei um die folgende Zeile und die 
Objektdefinition (OBJ=...) um src/Ausgabe.o erweitert haben, 
haben Sie es auch schon geschafft: 

src/Ausgabe.o: src/Ausgabe.c src/Editor.h pre/Editor.pre 

Wenn Sie den Editor nicht extra abtippen wollen, so finden Sie 
ihn ebenso wie die Quelltexte im Verzeichnis V0.3 der Diskette 
zum Buch. Starten Sie den Editor, und geben Sie mehrere Zeilen 
ein (mit a = Append). Verlassen Sie anschließend die Testumge¬ 
bung durch Escape. Danach können Sie das Fenster verschieben, 
vergrößern, verkleinern usw. und somit ausprobieren, ob der In¬ 
halt des Fensters wirklich immer korrekt ausgegeben wird. 

Da wir bei der Ausgabe sehr viel über Effizienz gesprochen ha¬ 
ben und uns davor auch schon den Assembler-Quelltext angese¬ 
hen haben, den der C-Compiler "ausgestoßen" hat, wollen wir 
diese Kenntnisse nun dazu benutzen, unser Programm noch et¬ 
was effizienter zu machen. 

Sie erinnern sich sicher noch, daß der C-Compiler den Ausdruck 
"*var++" etwas ungünstig übersetzt hatte. Lassen wir das Inkre¬ 
ment (++) weg und bearbeiten dies extra, so erzeugt der C-Com¬ 
piler bereits einen besseren Code. Übersetzen Sie dazu das fol¬ 
gende kleine Testprogramm so, daß Sie dessen Assembler- 
Quelltext erhalten: 

mainO 

i 

regiSter char *ptr; 
char String[10]; 
regiSter short n; 

for (n = 0, ptr = string; n < 10; n++) 

♦ptr++ = 0; 

for (n = 0, ptr = string; n < 10; n+-»', ptr++) 

♦ptr = 0; 

> 
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In der ersten For-Schleife wird der Zeiger ptr bei der Zuwei¬ 
sung inkrementiert, während er in der zweiten Schleife extra 
inkrementiert wird. Übersetzen Sie das Progrämmchen mit fol¬ 
gender Anweisung: 

cc test.c -a -t 

Sie erhalten den Assembler-Quelltext mit dem Namen Test.asm, 


der bei unserem Aztec-C-Compiler folgendermaßen aussiehc 

§ 

mainO 

! 

public _main 
_main: 

link a5,#.2 
movem.l .3,“(sp) 

i 

« 

regiSter char *ptr; 

f 

char string[10]; 

t 

regiSter short n; 

1 

i 

move.l #0,cl4 
lea *10(a5),a0 
move.l a0,a2 
bra .7 

.6 

for (n s 0, ptr = string; n < 10; 

move.l a2,a0 
add.l #1,a2 
clr.b (aO) 

.4 

add.w #1,d4 
.7 

cmp.w #10,d4 
blt .6 
.5 

f 

♦ptr-*”»- = 0; 

move.l #0,d4 
lea -10(a5),a0 
move.l a0,a2 
bra .11 

.10 

for <n = 0, ptr « string; n < 10; rH-+, ptr-*-+) 

clr.b (a2) 

.8 

add.w #1,d4 
add.l #1,a2 

.11 

cmp.w #10,d4 
blt .10 

♦ptr » 0; 
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I J 

.12 

movem.l (sp)'*‘,.3 

unlk a5 

rts 

.2 equ '10 
.3 reg ci4/a2 
public .begin 
dseg 
end 

Schauen Sie sich insbesondere die beiden Schleifenkörper an, 
also für die erste Schleife von Label .6 bis Label .7 und für die 
zweite Schleife von Label .10 bis Label .11. Sie sehen selbst, daß 
die erste Schleife hier vier Befehle braucht, während die zweite 
mit drei Befehlen auskommt. Dabei ist besonders wichtig, daß 
diese Befehle so oft durchlaufen werden, wie der Schleifenzähler 
vorgibt. Dieser Befehl wirkt sich also um so stärker aus, je öfter 
die Schleife durchlaufen wird. 

Sie sehen, es lohnt sich, den Assembler-Quelltext einmal genauer 
unter die Lupe zu nehmen. Zwar geben sich die Compiler-Her¬ 
steller alle Mühe, ihr Produkt so effizient wie möglich zu ma¬ 
chen, doch besser als von Hand erstellter Assembler-Code kann 
ein Compiler nicht sein. Im obigen Testprogramm würde minde¬ 
stens noch ein weiterer Befehl wegfallen, so daß nur noch ein 
CLR.B (A2)+ übrigbleiben würde. Auch der Schleifenzähler 
würde anders realisiert werden, aber das steht auf einem anderen 
Blatt. 

Wir, also die Autoren, sind nun in einer Zwickmühle. Einerseits 
möchten wir Ihnen zeigen, wie man möglichst optimale Pro¬ 
gramme schreibt, andererseits sind optimale Programme meist 
schlechter lesbar oder weniger einsichtig, so daß Sie vielleicht 
Schwierigkeiten haben, sie zu verstehen. Sie wissen ja, daß es 
vor allem in C keine Probleme bereitet, unlesbare Programme zu 
schreiben. Daher werden wir weiterhin einen Kompromiß zwi¬ 
schen Lesbarkeit und Effizienz eingehen. 
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4.3.7 Der Cursor 

Um den Text zu verändern, müssen wir jede Textstelle errei¬ 
chen, also den Cursor überall hinbewegen können. Wir werden 
daher im folgenden unseren Editor dahingehend erweitern, daß 
man den Cursor sowohl über die Cursor-Tasten der Tastatur als 
auch mit der Maus bewegen kann. Erreicht der Cursor dabei den 
Rand des Fensters, so muß dessen Inhalt gescrollt werden, damit 
man auch außerhalb des Fensters liegende Textstellen erreichen 
kann. Dies gilt vor allem für die vertikale Bewegung des Cur¬ 
sors, da die zu bearbeitenden Texte meist aus mehr Zeilen be¬ 
stehen als in unser Fenster passen. Aber auch horizontales Scrol¬ 
ling muß möglich sein, da es durchaus sein kann, daß einzelne 
Zeilen breiter sind als das Editorfenster, vor allem, wenn wir 
das Fenster verkleinert haben. 

Bei der Cursor-Bewegung müssen wir das Folding berücksichti¬ 
gen. Sie erinnern sich, daß wir bereits festgestellt haben, daß 
zwei Zeilen, die im Editorfenster direkt untereinander liegen, im 
Text nicht zwingendermaßen direkt aufeinander folgen müssen. 
Enthält eine Zeile eine Faltenanfangsmarkierung, so sind alle 
folgenden Zeilen bis zur dazugehörigen Faltenendemarkierung 
unsichtbar, und die im Fenster nächste Zeile ist die, die auf die 
Faltenendemarkierung folgt. Das bedeutet, daß wir die Zeilen¬ 
position des Cursors nicht direkt über seine Position im Fenster 
bestimmen können. Ebenso wie bei dem Feld zeilenptr brauchen 
wir auch hier wieder ein Feld, das für jede Zeile, die im Edi¬ 
torfenster sichtbar ist, deren Zeilennummer bereithält. 

Befindet sich der Cursor auf einer Zeile, so erhalten wir seine 
Zeilenposition über dieses Feld, das wir zeilennr nennen werden. 
Zusätzlich zu der realen Zeilenposition benötigen wir noch die 
Position bezüglich des Fensters, damit wir auf das Feld zeilennr 
zugreifen können. Damit wir die Mühe nicht ohne Grund auf 
uns nehmen, werden wir auch Folding bereits implementieren. 
Dies hat den Vorteil, daß wir die Funktionen dahingehend testen 
können, ob sich diese auch mit Folding korrekt verhalten. 

Das nächste Problem sind die Tabulatoren. Der Editor Z, der 
zum Aztec-C-Compiler mitgeliefert wird, handhabt Tabulatoren 
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so, daß der Cursor entsprechend viele Spalten überspringt, wenn 
er über Tabulatoren bewegt wird. Dadurch hängt die Cursor- 
Bewegung von dem Zeichen ab, auf dem sich der Cursor gerade 
befindet. Dies ist auch der Grund, warum sich der Cursor nicht 
hinter eine Zeile setzen läßt, sondern immer nur auf das letzte 
Zeichen der Zeile. Wir wollen den Cursor aber völlig frei posi¬ 
tionierbar lassen, auch wenn uns das ein paar kleine Probleme 
bei der Eingabe von Zeichen bringt. (Was passiert, wenn man 
einen Tabulator mit einem anderen Zeichen überschreibt? Wird 
der restliche Text nach links gerückt?) Dies bedeutet aber, daß 
die horizontale Positionierung des Cursors relativ simpel wird. 

Während es mit dem vertikalen Scrolling keine großen Probleme 
geben wird, sieht dies beim horizontalen Scrolling schon ein 
klein wenig anders aus. Wenn der Inhalt des Fensters nach rechts 
gescrollt wird, so müssen wir den linken Rand neu ausgeben, 
wofür sich unsere Funktion printAll eignet. Wir müssen ihr nur 
vormachen, daß das Fenster lediglich ein Zeichen breit ist. Da¬ 
bei tritt das Problem auf, daß das letzte Zeichen bei der Aus¬ 
gabe immer entweder ein Blank oder ein Punkt ist, welcher dann 
davon zeugt, daß die Zeile breiter als das Fenster ist (Variable 
lastchar in der Funktion convertLineForPrint). Das wiederum 
bedeutet, daß, wenn wir nur um eine Spalte scrollen, lauter 
Punkte in der ersten Spalte ausgegeben werden würden. Wir 
müssen an dieser Stelle zugeben, daß wir dieses Problem auch 
erst beim Ausprobieren bemerkt haben. Wir werden es umgehen, 
indem wir eine Spalte mehr konvertieren lassen, als wir eigent¬ 
lich brauchten, und dann bei der Ausgabe einfach das letzte 
Zeichen vergessen. Ein weiteres Problemchen besehtt darin, daß 
wir auch den rechten Rand neu ausgeben lassen müssen, da das 
letzte Zeichen, wie bereits erwähnt, ja immer ein Blank oder ein 
Punkt sein muß. Verschieben wir den Fensterinhalt aber nach 
rechts, so stehen in der letzten Spalte irgendwelche Zeichen, die 
wir überschreiben müssen. 

Die Neuausgabe des rechten Randes tritt auch dann auf, wenn 
wir nach links scrollen. Wenn wir auch dazu die Funktion 
printAll nehmen wollen, so müssen wir dem Editor nicht nur 
vorgaukeln, daß das Fenster nur ein (bzw. zwei) Zeichen breit 
ist, sondern auch, daß es einen sehr breiten linken Rand hat. 
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damit unser Text wirklich am rechten Rand erscheint. Wir müs¬ 
sen dabei eine Spalte mehr ausgeben als gescrollt wurde, da die 
letzte Spalte ja eh nur Blanks und Punkte enthielt, die wir wie¬ 
der überschreiben müssen. 

Dann könnten wir doch gleich eine neue Funktion schreiben, die 
eine Ausgabe ermöglicht, bei der die erwähnten Probleme nicht 
auftreten, meinen Sie? Klar, das könnten wir schon. Nur, wenn 
wir die Ausgabe erweitern, so daß beispielsweise C-Befehle fett 
gedruckt werden, so müßten wir diese Änderung in beiden Aus¬ 
gabefunktionen vornehmen. Wenn wir dann vielleicht noch ein 
paar Funktionen zur Ausgabe einbauen, so verlieren wir bald die 
Übersicht, wo überall Änderungen vorzunehmen sind. Solange 
wir unsere bisherigen Funktionen nicht übermäßig verkompli¬ 
zieren, wollen wir uns daher auf diese beschränken und sie den 
Umständen entsprechend erweitern. 

Was das Scrolling anbelangt, so sind wir mit unseren Überlegun¬ 
gen nun fertig, und wir können uns dem Folding zuwenden. Als 
provisorische Faltenanfangsmarkierung definieren wir eine Zeile, 
die mit "/*#FOLD:" anfängt, während das Faltenende durch eine 
Zeile markiert wird, die mit "/*#ENDFD" beginnt. Beide Zei¬ 
chenfolgen müssen in der momentanen Programmversion der 
Einfachheit halber direkt am Anfang der Zeile stehen, also ohne 
vorangestellte Blanks. Sie haben sicherlich erkannt, daß die Mar¬ 
kierungen mit den beiden Zeichen /* beginnen, die in C einen 
Kommantar einleiten. Dies ist notwendig, da der C-Compiler 
diese Zeilen überlesen muß. Später werden wir die Markierun¬ 
gen variabel machen, so daß auch die Programmierer anderer 
Sprachen die Faltentechnik nutzen können. 

Damit Sie erkennen, was in einer Falte liegt, können Sie hinter 
das /*#FOLD: einen Kommentar setzen, aus dem hervorgeht, 
welchen Zweck der Programmtext hat, der in der Falte liegt. Ist 
eine Falte verdeckt, so sehen Sie von dieser nur die Faltenan¬ 
fangsmarkierung, also das /*#FOLD: mit dem Kommentar. Um 
sich nun den Inhalt dieser Falte ansehen zu können, bewegen Sie 
den Cursor auf diese Zeile und drücken Ctrl-F (F wie Falte). 
Nun sehen Sie nur noch das, was in der Falte liegt. Da Sie Fal¬ 
ten beliebig verschachteln können, müssen wir dies bei der Aus- 
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gäbe berücksichtigen. Zuerst definieren wir den Level jeder 
Zeile, also die Tiefe der Falte, in der die Zeile liegt. Die erste 
Zeile im Text erhält den Level Null. Nach einer Faltenanfangs¬ 
markierung wird der Level um Eins erhöht, und nach einer 
Faltenendemarkierung dementsprechend um eins vermindert. Im 
folgenden Beispiel stehen die Falten-Level jeweils ganz links, 
und die Zeilen sind entsprechend ihrem Falten-Level eingerückt: 

0 Zeile 1 

0 /*#FOLD: Zeile 2 */ 

1 Zeile 3 

1 /*#FOLD: Zeile 4 •/ 

2 Zeile 5 

2 /*#ENDFD Zeile 6*/ 

1 Zeile 7 

1 /*#ENDFD Zeile 8 */ 

0 Zeile 9 

0 /*#FOLD: Zeile 10 */ 

1 /*#F0LD: Zeile 11 V 

2 Zeile 12 

2 /*#EM0FD Zeile 13 */ 

1 Zeile 14 

1 /*#EN0FD Zeile 15 V 

0 Zeile 16 

In unserer Editor-Struktur definieren wir zwei Variablen, min- 
fold und maxfold. Im Fenster werden nur die Zeilen ausgegeben, 
deren Level zwischen minfold und maxfold liegt. Auch läßt sich 
der Cursor nur innerhalb dieser Zeilen bewegen, so daß Sie mit 
dem Cursor eine Falte nicht verlassen können, es sei denn. Sie 
verlassen diese Falte explizit, indem Sie Ctrl-E (E wie Exit) 
drücken. Da es aber sinnvoll sein kann, daß man mehrere Level 
gleichzeitig sieht, wirkt Ctrl-F auf zweierlei Weise: 

Befindet sich der Cursor auf einer Faltenanfangsmarkie¬ 
rung, so werden minfold und maxfold auf den Level der 
folgenden Zeile gesetzt, so daß Sie nur noch die entspre¬ 
chende Falte sehen. 

Andernfalls wird nur maxfold um eins erhöht, so daß Sie 
zusätzlich zur momentanen Falte auch noch alle Falten se¬ 
hen, deren Level eins höher liegen; Sie falten den Text 
also quasi wieder auseinander. 

Ctrl-E dagegen wirkt immer gleich: Es vermindert zuerst max¬ 
fold um eins. Wenn dann minfold größer als maxfold ist, so wird 
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es auf maxfold gesetzt. Damit haben Sie alle Möglichkeiten, sich 
den Text anzusehen. Anhand des Beispieltextes sieht dies wie 
folgt aus: 

Am Anfang sind minfold und maxfold Null, so daß sich 
Ihnen der Text so darstellt: 

0 Zeile 1 

0 /*#FOLD: Zeile 2 */ 

0 Zeile 9 

0 /*#FOLD: Zeile 10 */ 

0 Zeile 16 

Sie sehen nur die Zeilen, deren Falten-Level zwischen 
minfold und maxfold liegen, also null sind. Drücken Sie 
nun Ctrl-F, während der Cursor auf Zeile 1 steht, so wird 
der gesamte Text aufgefaltet, und Sie sehen folgendes: 

0 Zeile 1 

0 /*#FOLO: Zeile 2 V 
1 Zeile 3 
1 /*#F0LD: Zeile 4 V 

1 Zeile 7 

1 /*«NDFD Zei le 8 V 

0 Zeile 9 

0 /*#F0LD: Zeile 10 V 

1 /*#F0LD: Zeile 11 V 

1 Zeile 14 

1 /*#EMDFD Zeile 15 V 

0 Zeile 16 


Nochmaliges Drücken von Ctrl-F würde den gesamten 
Text sichtbar machen, da der maximale Falten-Level aller 
Zeilen zwei ist. Drücken Sie nun zuerst Ctrl-E, damit Sie 
wieder nur alle Zeilen mit dem Falten-Level null sehen, 
bewegen Sie den Cursor auf Zeile 2, und drücken Sie Ctrl- 
F. Sie treten damit in die Falte hinein und sehen nur noch 
deren Inhalt: 

1 Zeile 3 

1 /*#F0LD: Zeile 4 */ 

1 Zeile 7 

1 /*#EN0FD Zeile 8 V 

Nun wirkt aber ein auf gefalteter Text eher unübersichtlich, denn 
woran erkennen Sie, ob die zu einer Faltenanfangsmarkierung 
gehörende Falte bereits auf dem Bildschirm zu sehen ist oder 
nicht? Es wirkt sehr verwirrend, wenn man maxfold auf den 
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maximalen Zeilen-Level gesetzt hat, während minfold auf Null 
geblieben ist, und man dann dauernd Faltenmarkierungen im 
Text sieht, obwohl gar keine Falten mehr verdeckt sind! Aus 
diesem Grund werden wir alle Faltenendemarkierungen und die 
Faltenanfangsmarkierungen in schwarzer Schrift ausgeben, die 
zu Falten gehören, deren Inhalt man auf dem Bildschirm sehen 
kann. Wenn man dann auf eine Faltenanfangsmarkierung in 
normaler (weißer) Farbe stößt, so kann man sicher sein, daß 
man in diese Falte noch eintreten kann. 

Doch kommen wir nun zur Realisation: Was die Cursor-Bewe¬ 
gung anbelangt, so brauchen wir vier Funktionen, die den Cur¬ 
sor in jede Richtung bewegen können: 

cursorRight, cursorLeft, cursorUp und cursorDown. 

Diese benötigen keine Parameter und geben TRUE zurück, wenn 
der Cursor wirklich bewegt wurde, und FALSE, falls nicht, der 
Cursor also zum Beispiel bereits am Zeilenende war. Im Moment 
haben wir zwar noch keine Verwendung für diesen Rückgabe¬ 
wert, aber wenn wir den Editor programmierbar machen, kann 
es sinnvoll sein zu wissen, ob der Cursor wirklich bewegt wor¬ 
den ist. Dies kann man dann z.B. als Abbruchkriterium für 
Schleifen verwenden. Diese Funktionen zur Cursor-Bewegung 
rufen gegebenenfalls Funktionen auf, die den Inhalt des Editor¬ 
fensters in die entsprechende Richtung scrollen. Diese Funktio¬ 
nen heißen analog: 

scrollieft, scroURight, scrollDown und scroUUp. 

Es ist dabei zu beachten, daß cursorRight die Funktion scroll- 
Left aufruft; dies gilt für die anderen Funktionen analog. Als 
Parameter wird nur.die Anzahl der Zeilen bzw. Spalten überge¬ 
ben, um die gescrollt werden soll. Der Parametertyp ist 
UWORD. Alle Scroll-Funktionen sind vom Typ void; sie liefern 
also kein Ergebnis zurück. 

Aufrufen müssen wir diese Funktionen auch noch, und zwar 
nachdem die korrespondierende Taste gedrückt worden ist. Wir 
benötigen also eine Funktion, an die wir die Zeichen übergeben, 
die uns der Tastaturtreiber geschickt hat, und die für uns die 
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Cursor-Funktionen aufruft. In dieser Funktion muß auch das 
Ein- und Ausfalten behandelt werden, da dies ja auch über die 
Tastatur erfolgt: 

void handleKeys(buf,len) 

UBYTE *buf; 

UWORD len; 

Die ganze Zeit haben wir nun von der Cursor-Bewegung ge¬ 
sprochen, sind aber noch nicht auf die Idee gekommen, den 
Cursor auch anzeigen zu lassen. Dies wird uns die Funktion 
Cursor abnehmen, die den Cursor im COMPLEMENT-Modus 
ausgibt. Wenn wir diese Funktion einmal vor dem Wait-Befehl 
in unserer Hauptschleife und einmal danach aufrufen, so sehen 
wir den Cursor immer dann, wenn unser Programm nichts zu 
tun hat; andernfalls ist der Cursor verschwunden und kann somit 
nicht von irgendwelchen Operationen beeinträchtigt werden. 

void Cursore) 

Damit hätten wir mal wieder alle wichtigen Funktionen beisam¬ 
men für unser neues Modul, so daß wir direkt an die Imple¬ 
mentierung gehen können, nachdem wir unsere Datei Editor.h 
entsprechend erweitert haben: 

#define FOLDPEN 2L 

#define ZEILENPTR(n) aktuellerEditor->ze{lenptrln] 

#define ZEILENNR(n) aktueUerEditor->zeilennr[n] 

«define ZLF FSE 64 
iKdefine ZIF^FOLD 63 

FOLDPEN ist die Farbe, in der Faltenmarkierungen ausgegeben 
werden, also normalerweise Schwarz. Die beiden Makros ZEI- 
LENPTR und ZEILENNR sollen lediglich den Zugriff auf Ele¬ 
mente des entsprechenden Feldes vereinfachen. Statt 

aktuellerEditor■>zeilenptr[n] 

schreiben Sie einfach: 


ZEILENPTR(n) 
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Die beiden letzten Defines gehören zu der Datenstruktur Zeile, 
genauer zu den Flags in der Zeile-Struktur. Wenn das Flag 
ZLF_FSE gesetzt ist, so handelt es sich bei der Zeile um eine 
Faltenmarkierung, wobei egal ist, ob es sich um eine Faltenan¬ 
fangs- oder Faltenendemarkierung handelt (FSE = Fold Start- 
End). ZLF_FOLD dagegen gibt den Falten-Level der Zeile an, 
also Null für alle Zeilen, die zu keiner Falte gehören. Beachten 
Sie dabei bitte, daß die Faltenanfangsmarkierung selbst nicht mit 
zur Falte gehört! Der maximale Falten-Level ist in unserem Fall 
63, was sicher mehr als großzügig ist. 

Unsere Editor-Struktur wurde ebenfalls erweitert, so daß wir 
diese hier nochmal ganz abdrucken: 

struct Editor 

< 

struct Editor *succ; 
struct Editor *pred; 
struct Window *window; 
struct BL ist block; 
struct ZList Zeilen; 

UBYTE puffer[MAXBREITE]; 

UBYTE tabstringCMAXBREITEl; 

UWORD anz_zeilen; 

struct Zeile *aktuell; 

struct Zeile *zeilenptr[MAXHOEHE]; 

UWORD zeilennr[MAXHOEHE]; 

UWORD toppos,leftpos; 

UWORD xpos,ypos; 

UWORD wdy; 

UWORD changed:1; 

UWORD insert:1; 
struct RastPort *rp; 

UWORD xoff,yoff; 

UWORD xscr,yscr; 

UWORD cw,ch; 

UWORD wcw,wch; 

UWORD xrl,xrr,yru,bl; 

UWORD minfold; 

UWORD maxfold; 

>; 


Neu sind dabei folgende Elemente: 
zeilennrf ] 

Enthält die Nummern aller Zeilen, die im Fenster sichtbar sind 
(siehe auch zeilenptr). 
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leftpos 

Wenn im Fenster nach links gescrollt wird, so entspricht die er¬ 
ste Spalte des Fensters nicht mehr der ersten Spalte des Textes, 
sondern einer der folgenden Spalten, leftpos gibt die Nummer 
der Spalte an, die direkt links vom Fenster liegt. Normalerweise 
ist leftpos also null, was bedeutet, daß die erste Spalte, die im 
Fenster sichtbar ist, die Nummer Eins trägt. 

wdy 

Ist die bereits erwähnte Zeilenposition des Cursors, bezogen auf 
das Fenster. Dieser Wert liegt zwischen null und (aktuellerEdi- 
tor->wch -1). 

xscr, yscr 

Diese beiden Variablen geben den rechten/unteren Rand des 
Fensters an, der für das Scrollen benötigt wird. In der Abbil¬ 
dung zur Textausgabe entspricht xscr = (xrl -1) und yscr = (y - 
1) (jeweils in Pixeln gemessen). 

minfold, maxfold 

Geben den minimalen und maximalen Falten-Level an, der be¬ 
stimmt, welche Falten auf dem Bildschirm erscheinen und wel¬ 
che nicht. 

Nach dieser Vorarbeit wollen wir jetzt das neue Modul Cursor 
implementieren, das alle zuvor beschriebenen Funktionen zum 
Cursor beinhaltet: 

<src/Cursor.c> 

^************ 

* 

* Includes: 

* 

************! 

#include <exec/type8.h> 

#inclüde <intuition/intuftion.h> 

#include “src/Editor.h" 
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^*********** 

* 

* Defines: 

* 

***********j 


#define CSI 0x9B 
#define CUU *A' 
#define CUD 'B* 
#define CUF 'C* 
#define CUB 'D* 
#define SU 'S* 
#define SO 'T' 

#define CFOLD 6 
#define CENDF 5 


j********************** 

* 

* Externe Funktionen: 

* 

********************** y 


void SetDrMd(),RectFiU(),printAU(); 
struct Zeile *nextLine(),*prevLine(); 


j********************* 
* 


♦ Externe Variablen: 

* 

********************* ^ 


extern struct Editor *aktuellerEd1tor; 
extern UWORD spaltenOec; 


!*************** 
* * 

* Funktionen: * 

* * 
*************** 


/ 


* 

* restoreZellenptr: 

* 

* Restauriert das zellenptr/nr-Feld 

* fuer alle Zellen Im Fenster plus 

* der naechsten Zelle. 

* Die erste Zelle muss allerdings 

* korrekt sein! 
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void restoreZei lenptrO 
i 

reg 1 Ster UUORD n; 

register struct Zeile **zptr,*z; 

reg 1 Ster UWORD "“"prir; 

UWORD znr; 

for (n = aktuellerEditor->wch, 

zptr = aktueUerEditor->zei lenptr, 
pnr = aktueUerEditor->zeilennr, 
z = *zptr++, znr = *pnr+-»-; n; n--) 

< 

*zptr-»-+ = (z = nextLine(z,&znr)); 

♦pnr-»”»- = znr; 

> 

> 

y********************************** 

* 

* Cursor: 

* 

* Setzt bzw. loescht den Cursor an 

* der aktuellen Position. 

* 

★★********************************y 

void Cursore) 

C 

register struct RastPort *rp; 
register LONG x,y; 
register LONG cw,ch; 

SetDrMd(rp = aktuellerEditor->rp,COMPLEMENT); 

x = (aktuellerEditor->xpos - aktuellerEditor->leftpos - 1) 
*(cw = aktuellerEditor*>cu) + aktuellerEditor->xoff; 
y = aktuellerEditor’>udy 

*(ch = aktuellerEditor->ch) + aktuellerEditor->yoff; 
RectFill(rp,x,y,x cw-1,y + ch-1); 

SetDrMd(rp,JAM2); 


^******************************* 

* 

* scrollRight(anz): 


* Scrollt den Fensterinhalt um 

* anz Zeichen nach rechts. 

* 

* anz = Anzahl der Zeichen. 
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void scrollRight(anz) 
regiSter DWORD anz; 

C 

regiSter DWORD y^ch^count; 
reg 1 Ster struct Zeile **z; 

DWORD wcw,xoff,leftpos; 

aktuellerEditor’>leftpos -= anz; 

if (anz >= aktueUerEditor->wcw) 
printAUO; 
eise 
C 

/* Scrollen: V 

ScrollRaster(aktuellerEditor->rp, 

-anz * (LONG)aktuellerEditor’>cu,OL, 

(LONG)aktuellerEditor->xoff, 

(LONG)aktuellerEditor->yoff, 
(LONG)aktuellerEditor->xscr, 

(LONG)aktuellerEditor->yscr); 

/* nun printAUO ueberlisten: V 
wcw = aktuellerEditor->wcu; 
aktuellerEditor->wcw = anz + 1; 
spaltenDec » 1; 

y * aktuellerEditor->yoff; 
ch = aktuellerEditor->ch; 
count = aktuellerEditor->wch; 

/* Zeilen ausgeben: V 

for (z = aktuellerEditor->zeilenptr; count-- 

&& (*z != NDLL); 

z-f-»-, y += ch) 
printLine(*z,y); 

spaltenDec = 0; 

/* Rechten Rand nochmals ausgeben, wegen letztem Zeichen */ 

leftpos = aktuellerEditor->leftpos; 

xoff = aktuellerEditor->xoff; 

aktuellerEditor->wcw = 2; 

aktuellerEditor->leftpos (y = wcw - 2); 

aktuellerEditor->xoff •»■= aktuellerEditor->cw * y; 

y = aktuellerEditor->yoff; 
count = aktuellerEditor->wch; 

/* Zeilen ausgeben: V 

for (z = aktuellerEditor->zeilenptr; 

count-- && (♦z != NDLL); 

Z++, y += ch) 
printLine(*z,y); 
aktuellerEditor->wcw = wcw; 
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aktuellerEditor->leftpos= leftpos; 
aktueUerEditor->xoff = xoff; 

> 

> 


y******************************* 

★ 

* scroULeft(anz): 

* 

* Scrollt den FensterInhalt um 

* anz Zeichen nach links. 


* anz = Anzahl der Zeichen. 

* 

**★****************************/ 


void scrollLeft(anz) 
regiSter DWORD anz; 
i 

regiSter DWORD y,ch,count; 
register struct Zeile **z; 

DWORD ucw^xoff,leftpos; 

aktuellerEditor->leftpos += anz; 

if (anz >= aktuellerEditor*>wcw) 
printAll(); 
eise 

/* Scrollen: */ 

ScrollRaster(aktuellerEditor->rp, 

anz * (LONG)aktuellerEditor‘>cu,OL, 

(LONG)aktuellerEditor->xoff, 

(LONG)aktuellerEditor->yoff, 
(LONG)aktuellerEditor->xscr, 

(LONG)aktuellerEditor->yscr); 

/* nun printAll() ueberlisten: V 

wcw = aktuellerEditor*>wcw; 

leftpos = aktuellerEditor*>leftpos; 

xoff = aktuellerEditor->xoff; 

aktuellerEditor’>wcw = anz +1; 

aktuellerEditor*>leftpos += <y = wcw - anz - 1); 

aktuellerEditor->xoff +* aktuellerEditor’>cw * y; 

y = aktuellerEditor->yoff; 
ch = aktuellerEditor->ch; 
count = aktuellerEditor->wch; 

/* Zeilen ausgeben: V 

for (z = aktuellerEditor->zeilenptr; 

count-- && (*z != NDLL); 

Z++, y += ch) 
printLine(’*'z,y); 
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aktueUerEditor*>wcw = wcw; 
aktuellerEditor->leftpos= leftpos; 
aktuellerEditor->xoff = xoff; 

> 

> 

^******************************* 

* 

* scrollUp(anz): 

* 

* ScroUt den Fensterinhalt um 

* anz Zeilen nach oben. 

* Es muessen aber noch anz 

* Zeilen existieren! 

* 

* anz = Anzahl der Zeilen. 

* 

*******************************^ 

void scrollUp (anz) 
regiSter UWORD anz; 
i 

register struct Zeile *z,**zptr,**zold; 
register UWORD n,wch = aktuellerEditor->wch,y; 

UWORD znr,*pnr,*oldnr; 

if (anz >= weh) 
i 

/* Fenster neu ausgeben, ohne zu Scrollen */ 

/* Zuerst die oberste Zeile suchen: V 
n = weh; 
if (anz > weh) 

< 

z - ZEILENPTR(n); 
znr - ZEILENNR(n); 
while (•►•»■n < anz) 

z = nextLine(z,&znr); 

> 

eise 

z = ZEILENPTR(n - 1); 
znr = ZEILENNR(n - 1); 

> 

/* z zeigt nun vor die oberste Zeile des Fensters V 
for (n = 0, zptr = aktuellerEditor->zeilenptr, 

pnr = aktuellerEditor*>zeilennr; n <= weh; n+-»-) 

< 

*zptr++ = (z = nextLine(z,&znr)); 

♦pnr-»”»- = znr; 

> 




Betriebssystemprogrammierung 


607 


/* Nun noch Fenster neu ausgeben: */ 
printAlU); 

> 

eise 

< 

/* Scrollen: V 

ScrollRaster(aktuellerEditor->rp, 

0L,anz * (LONG)aktuellerEditor->ch, 
(LONG)aktuellerEditor->xoff, 

(LONG)aktuellerEditor->yoff, 
(LONG)aktuellerEditor->xscr, 

(LONG)aktuellerEditor*>yscr); 

/* zeilenptr/nr neu berechnen: V 

zptr = aktuellerEditor'>zeilenptr; 

zold = &(ZEILENPTR(anz)); 

pnr = aktuellerEditor->zeilennr; 

oldnr = &(ZEILENNR(anz)); 

for (n = 0; n <= weh - anz; n^-»-) 

i 

’^zptr++ = *zolch”«-; 

*pnr++ = ♦oldnr-»"»-; 

> 

z = *--zold; 

zold = zptr - 1; /* merken fuer Ausgabe! V 

znr = ♦--oldnr; 
oldnr = pnr - 1; 
while <n <= weh) 

< 

♦zptr-»--»- = <z = nextLine(z,&znr)); 

♦pnr-»--»- = znr; 
n+-»-; 

> 

/♦ Zeilen neu ausgeben: ♦/ 
for (n=anz, y=aktuellerEditor-> 

yof f-»-(wch-anz)^aktuel lerEdi tor->ch; 
(n && (♦zold != NULL)); n--, zolcH--»-, 

y -»-= aktuel lerEdi tor->ch) 

printLine(^zold,y); 

> 

aktuel lerEdi tor->toppos -»-= anz; 

> 

y******************************* 

* 

♦ scrollDown(anz): 

* 

♦ Scrollt den Fensterinhalt um 

♦ anz Zeilen nach unten. 

♦ Es muessen aber noch anz 

♦ Zeilen existieren! 
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* anz = Anzahl der Zeilen. 

* 

*******************************y 


void scrollDoun (anz) 
regiSter DWORD anz; 

C 

register struct Zeile *z,**zptr,**zold; 

regiSter DWORD n,wch = aktuellerEditor->wch,y; 

DWORD znr,*pnr,*oldnr; 

if (anz >= weh) 

C 

/* Fenster neu ausgeben, ohne zu Scrollen */ 

/* Zuerst rueckuaerts nach oberster Zeile suchen: V 
for (z = ZEILENPTR(O), znr = ZEILENNR(O), 

n « anz - weh; n; n--) 

z = prevLine(z,&znr); 

/* z zeigt auf erste Zeile nach Fensterunterkante. V 
for (n = 0, zptr = &(ZEILENPTR(wch)), 

pnr - &(ZEILENNR(wch)); 

n <= weh; n++) 
i 

♦zptr-- = z; 

♦pnr-- = znr; 
z = prevLine(z,&znr); 

> 

/♦ Nun noch Fenster neu ausgeben: ♦/ 
printAllO; 

> 

eise 

i 

/♦ Scrollen: ♦/ 

ScrollRaster(aktuellerEditor->rp, 

OL,-anz ♦ (LONG)aktuellerEditor->ch, 

(LONG)aktuellerEditor->xoff, 

(LONG)aktuellerEditor->yoff, 
(LONG)aktuellerEditor->xscr, 

(LONG)aktuellerEditor->yscr); 

/♦ zeilenptr neu berechnen: ♦/ 
zptr = &(ZEILENPTR(wch)); 
zold - &(ZEILENPTR(wch - anz)); 
pnr « &(ZEILENNR(wch)); 
oldnr » &(ZEILENNR(wch - anz)); 
for (n = 0; n <= weh - anz; n^+) 
i 

♦zptr-- = ♦zold--; 

♦pnr-- = ♦oldnr--; 

> 

for (z = ♦♦■••zold, znr = ♦■»••••oldnr, n = anz; n; n--) 
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t 

* 2 ptr-- = (2 = prevLine( 2 ,& 2 nr)); 

*pnr-- = 2 nr; 

> 

/* Zeilen neu ausgeben: V 

for (n = an 2 , y = aktuellerEditor->yoff; 

(n && (* 20 ld i= NULD); 
n--, 2 oIcH”»-, y += aktueUerEditor'>ch) 
printLine(* 2 old,y); 


aktuellerEditor->toppos *= an 2 ; 

> 


y**************************************** 

* 


* cursorLeft: 

* 

* Bewegt den Cursor um eine Stelle 

* nach links. Gibt FALSE 2 urueck, 

* wenn Cursor bereits in erster Spalte. 

* 


****************************************y 


BOOL cursorLeftO 
i 

if (aktuellerEditor*>xpos >1) 
i 

aktuellerEditor->xpos--; 

if (aktuellerEditor*>xpos <* aktuellerEditor->leftpos) 
scrollRight((UU0RD)1); 

return (TRUE); 

> 

eise 

return (FALSE); 


y***************************************** 

* 

* cursorRight: 

* 

* Bewegt den Cursor um eine Stelle 

* nach rechts. Gibt FALSE 2 urueck, 

* wenn Cursor bereits in let 2 ter Spalte. 

* 

*****************************************/ 


BOOL cursorRightO 

if (aktuellerEditor->xpos < MAXBREITE) 
i 


aktuellerEditor->xpos++, 
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if (aktuellerEditor->xpos 

>= (aktueUerEditor->leftpos aktuellerEditor->wcw)) 
scroULeft((UW0RD)1); 

return (TRUE); 

> 

eise 

return (FALSE); 


y***************************************** 


* cursorUp: 

* 

* Bewegt Cursor um eine Zeile nach oben. 

* Gibt FALSE zurueck, falls Cursor 

* bereits in erster Zeile. 

* 


*****************************************^ 


BOOl cursorUpO 
i 

UUORD hilf; 

if (aktuellerEditor’>wdy) 
aktuellerEditor->wdy--; 
eise 

if (prevLine(ZEILENPTR(0),&hilf)) 
scrollDown((UW0RD)1); 
eise 

return (FALSE); 

aktuellerEditor->ypos = ZElLENNR(aktuellerEditor->wdy); 
return (TRUE); 

> 



* 


* cursorDown: 

* 

* Bewegt Cursor um eine Zeile nach unten. 

* Gibt FALSE zurueck, falls Cursor 

* bereits in letzter Zeile. 

* 



BOOL cursorDownO 
i 

if (ZEILENPTR(aktuellerEditor*>wdy 1)) 
i 

if (++aktuellerEditor->wdy >* aktueUerEditor->wch) 

< 


scrollUp((UW0RD)1) 
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> 


aktuellerEditor->wdy- 

> 

aktueUerEditor->ypos = ZEILENNR(aktuel lerEdi tor->udy) 
return (TRUE); 


> 

eise 

return (FALSE); 


y********************************** 

* 

* halfPageUp: 


* Bewegt den Cursor um eine halbe 

* Seite nach oben. Der Text wird 

* analog um eine halbe Seite nach 

* unten gescrollt. 

* Gibt FALSE zurueck, falls Cursor 

* bereits in erster Zeile. 


**********************************^ 


BOOL halfPageUpO 

register UUORO max,n; 
register struct Zeile *z; 

UWORD hilf; 

max = aktuellerEditor->wch / 2; 
for (n = 0, z = ZEILENPTR(O); n < max; n++) 
if (!(z = prevLine(z,&hiIf))) 
break; 


if (n) 

C 

scrollDown(n); 

aktuellerEditor’>ypos = ZEILENNR(aktuellerEditor->wdy) 
return (TRUE); 

> 

eise 

return (FALSE); 


y********************************** 

* 

* halfPageDown: 


* Bewegt den Cursor um eine halbe 

* Seite nach unten. Der Text wird 

* analog um eine halbe Seite nach 

* oben gescrollt. 

* Gibt FALSE zurueck, falls Cursor 
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* bereits in letzter Zeile. 




BCX)L halfPageDownO 
C 

regiSter DWORD max,n; 
register struct Zeile *z; 

DWORD hilf; 

max = aktuellerEditor*>wch / 2; 

for (n = 0, z = ZEILENPTR(aktuellerEditor->wch - 1); 

n < max; n++) 

if (!(z = nextLine(z,&hiIf))) 
break; 


if (n) 

< 

scrollDp(n); 

aktuellerEditor->ypos = ZEILENNR(aktuellerEditor*>wdy); 
return (TRDE); 

> 

eise 

return (FALSE); 


* 

* handleKeys(buf,len): 

* 

* Behandelt Tastatur*Messages. 

4r 

* buf “ Puffer mit Zeichen. 

* len = Anzahl der Zeichen. 


*******************************y 


void handleKeysCbuf,len) 
register DBYTE ’^buf; 
register WORD len; 

i 

register DBYTE first; 
register struct Zeile *z; 


while (len > 0) 


first = *buf; 

buf++; 

len--; 

if ((first == CSI) && (len > 0)) 
i 

len--; 

switch (♦buf++) 
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i 

case CUU: 
cursorUpO; 
break; 
case CUD: 

cursorDownO; 
break; 
case CUF: 

cursorRightO; 
break; 
case CUB: 

cursorLeftO; 
break; 
case SU: 

halfPageOownO; 
break; 
case SD: 

halfPageUpO; 

break; 

default: 

buf--; 

leiT»-+; 

break; 

> 

> 

eise if ((first == CFOLD)&&(aktuellerEditor-> 

maxfold < ZLF FOLD)) 
i 

aktuel lerEdi tor->inaxf olch”»*; 

if (z = ZElLENPTR(aktueUerEditor->wdy)) 
if ((2 = 2 ->succ)->succ) 

/* Wenn es eine nachfolgende Zeile gibt: */ 
if (((ZEILENPTR(aktuellerEditor->wdy)-> 

flags & ZLF FOLD) 

< (z->flags & ZLF^FOLD)) 

&& ((z->flags & ZLF_FOLD)== 

aktuellerEditor’>maxfold)) 
i 

/* Wenn dieser Anfang einer neuen Falte ist: V 
aktuellerEditor->minfold = 

aktuellerEditor*>maxfold; 

ZEILENPTR(O) = z; 

ZEILENNR(O) = ZEILENNR 

(aktuellerEditor->wdy) + 1; 
aktuel lerEdi tor‘>w^ » 0; 

> 

restoreZei lenptrO; 

printAllO; 

aktuellerEditor*>ypos = ZElLENNR(aktuellerEditor->wdy); 

> 

eise if ((first « CENDF) && (aktuellerEditor->maxfold)) 
i 
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aktuellerEditor->maxfold--; 

if (aktueUerEditor->minfold > aktuel lerEditor->maxfold) 
aktueUerEditor->minfold = aktuel lerEdi tor->maxfold; 

if (((ZEILENPTR(0)->flags & ZLF_FOLD)> 

aktuel lerEdi tor->fnaxf old) 

II ((ZEILENPTR(0)->flags & ZLF_FOLD)< 

aktuellerEditor->minfold)) 
i 

ZEILENPTR(O) = prevLine(ZElLENPTR(0),&(ZElLENNR(0))); 
aktuellerEditor*>wdy = 0; 

> 

restoreZeilenptr(); 
printAllO; 

aktuellerEditor*>ypos = ZElLENNRCaktuellerEditor*>wdy); 

> 

eise 

putchar(first); 

> 

> 

Und nun wieder ein paar aufmunternde Worte zu den Funktio¬ 
nen im einzelnen und ein paar Besonderheiten im speziellen; 

Die Defines bestimmen die Zeichen, über die die Cursor- 
Bewegung und das Falten ausgelöst werden. Die Bezeich¬ 
nungen sind dem Amiga-DOS-Manual entnommen. Bei der 
Abfrage in handleKeys muß beachtet werden, daß die 
Zeichenfolgen für die Cursor-Bewegung zwei (bis drei) 
Zeichen lang sind: jeweils ein CSI gefolgt von dem in den 
Defines angegebenen Zeichen. 

Die Funktion restoreZeilenptr berechnet das zeilenptr- und 
das zeilennr-Feld neu, wobei sie davon ausgeht, daß die 
oberste Zeile korrekt ist. Diese Funktion wird benötigt, um 
nach dem Eintritt in eine Falte den Fensterinhalt neu aus¬ 
geben zu können. 

Die Scroll-Funktionen erlauben es, um mehr als eine Zeile 
bzw. ein Zeichen zu scrollen. Es darf sogar um mehr Zei¬ 
len bzw. Zeichen gescrollt werden, als auf den Bildschirm 
passen. Dadurch lassen sich die vertikalen Scroll-Funktio¬ 
nen später gut dafür verwenden, eine bestimmte Textstelle 
aufzusuchen. 
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Statt die Funktion printAll in den Scroll-Funktionen zu 
verwenden, wird eine for-Schleife benutzt, weil printAll 
auch die Ränder löscht, was für das Scrollen nicht nötig ist 
und nur Zeit kosten würde. 

Bei scrollUp und scrollDown muß das zeilenptr-/nr-Feld 
neu berechnet werden. Um dabei nicht das ganze Feld neu 
berechnen zu müssen, werden die Inhalte, die nach dem 
Scrollen noch gebraucht werden, entsprechend verschoben, 
eben so, wie auch die Zeilen verschoben (gescrollt) worden 
sind. 

Bei cursorUp und cursorDown muß wegen des Folding 
getestet werden, ob die nächste bzw. die vorige Zeile 
überhaupt in dem momentanen Level existiert. Dies wird 
von den Funktionen nextLine und prevLine übernommen, 
die entsprechend erweitert werden müssen. So wird diesen 
Funktionen ein Zeiger auf die aktuelle Zeilennummer 
übergeben, die dann entsprechend erhöht bzw. vermindert 
wird. 

Um vertikales Scrolling um mehr als eine Zeile testen zu 
können, wurden die Funktionen halfPageUp und halfPa- 
geDown eingebaut, die den Text jeweils um eine halbe 
Fensterseite nach oben bzw. unten scrollen. Die Position 
des Cursors bleibt dabei unverändert, zumindest die Posi¬ 
tion bezüglich des Fensters. 

Wenn Ctrl-F gedrückt wird, so muß der Editor feststellen, 
ob er sich auf einer Faltenanfangsmarkierung befindet. 
Eine solche ist dadurch definiert, daß der Level der aktu¬ 
ellen Zeile kleiner als der Level der folgenden Zeile ist, 
vorausgesetzt, es gibt eine folgende Zeile. Die folgende 
Zeile wird hier nicht mit nextLine bestimmt, da wir die 
nächste Zeile im Text brauchen, ohne Beachtung der Fal¬ 
tung. Wenn dann noch der Level der folgenden Zeile 
gleich dem maximalen Falten-Level plus eins entspricht, so 
handelt es sich bei der aktuellen Zeile um eine Faltenan¬ 
fangsmarkierung, da die nächste Zeile nicht sichtbar ist. 

Beim Austritt aus einer Falte muß sichergestellt sein, daß 
die oberste Zeile nicht zu der Falte gehört, die gerade 
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verlassen wurde, bevor restoreZeilenptr aufgerufen wird. 
Andernfalls stimmt der Fensterinhalt nicht. 

Alles klar? Na fein! Dann können wir ja die anderen Module 
entsprechend erweitern. Beginnen wollen wir mit dem Hauptmo¬ 
dul Editor, in dem zwei neue Funktionen deklariert werden 
müssen 

void handleKeysO,Cursore); 

Natürlich müssen die Funktionen nextLine und prevLine an das 
Folding angepaßt werden: 

struct Zeile *nextLine(zeile,pnr) 
register struct Zeile *zeile; 
regiSter UUORD *pnr; 

i 

register struct Zeile *z; 

register UWORD minfold = aktuellerEditor*>minfold; 
register UWORD maxfold s alctuellerEditor’>maxfold; 

if <z = Zeile) 
if (z->succ) 

i 

if ((z = z->succ)->succ) 

if (<z->flags & ZLF_FOLD) < minfold) 

< 

/* Nachfolgende Zeile liegt ausserhalb Falte V 

z - NULL; 

break; 

> 

eise 

*pnr += 1; 

eise 

C 

/* keine nachfolgende Zeile V 

z s NULL; 

break; 

> 

> 

while ((z->flags & ZLF^FOLD) > maxfold); 
eise 

z « NULL; 
return (z); 

> 

Die Funktion prevLine sieht genauso aus, nur daß ->succ überall 
durch ->pred ersetzt wird: 
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struct Zeile *prevLine(zeile,pnr) 
register struct Zeile *zeile; 
reg 1 Ster UUORD ’*^pnr; 

i 

register struct Zeile *z; 

register UWORD minfold = alctuellerEditor‘>minfold; 
register UUORD maxfold = aktuellerEditor*>maxfold; 

if (z = Zeile) 
if (z->pred) 
do 
< 

if <(z s z->pred)->pred) 

if <<z->flags & ZLF FOLD) < minfold) 
i 

/* Vorige Zeile liegt außerhalb der Falte */ 

z = NULL; 

break; 

> 

eise 

*pnr += 1; 

eise 

< 

/* keine vorige Zeile V 

z - NULL; 

break; 

> 

> 

while ((z*>flags & ZLF_FOLD) > maxfold); 
else 

z - NULL; 
return (z); 

> 

In der Funktion OpenEditor werden die zusätzlichen Elemente 
der Editor-Struktur initialisiert: 

ed->leftpos = 0; 
ed->wdy = 0; 
ed->minfold = 0; 
ed’>maxfold = 0; 

/* zeilenptr/nr-Array initialisieren: V 

for (n s 0, zptr * ed->zeilenptr, pnr * ed->zeilennr; 

n < NAXHOEHE; n+-»-, zptr-»«*', pnr-»>-i-) 
i 

♦zptr = NULL; 

♦pnr =1; 

> 
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Im Hauptprogramm ändern wir die Variablen: Statt SHORT 1 
fügen wir zwei neue hinzu: 

ULONG mouseX,mouseY; 

Auch die Hauptschleife bekommt ein anderes Gesicht, weswegen 
wir diese nochmal komplett auflisten: 

do 

C 

/♦ Cursor setzen: V 
Cursore); 

Signal = Wait<1L « edUserPort->mp_SigBit); 

/* Cursor wieder loeschen: V 
Cursore); 

while eimsg = GetMsgeedUserPort)) 
i 

dass = imsg*>Class; 

Code s imsg*>Code; 

qualifier = imsg->Qualifier; 
i address = ifnsg*>I Address; 

mouseX » imsg->MouseX; 

mouseY = imsg*>MouseY; 

ReplyMsgeimsg); 

/* Event bearbeiten: V 
switch eclass) 

< 

case RAWKEY: 

if ei ecode & lECOOE UP^PREFIX)) 
i 

inputEvent.ie^Code » code; 
inputEvent.ie^Qualifier = qualifier; 
if eeinputLen = RawKeyConverte 

&inputEvent,inputPuffer,MAXINPUTLEN,NULL) 

) >= 0 ) 

handleKeyseinputPuffer,inputLen); 

> 

break; 

case MeXJSEBUTTONS: 
i 

regiSter WORD x,y; 

if emouseX <» aktuellerEditor<>xoff) 

X = Gl¬ 
eise 

X = emouseX - aktuellerEditor->xoff) 
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/ aktueUerEditor->cw; 
if (++X >= aktueUerEditor->wcw) 

X = aktuellerEditor->ucw - 1; 

X += aktuellerEditor->leftpos; 
if (X > MAXBREITE) 

X - MAXBREITE; 

if (mouseY <= aktueUerEditor“>yoff) 

y = 0; 

eise 

y = (mouseY - aktueUerEditor->yoff) 
/ aktueUerEditor->ch; 


> 


if 

i 


> 


((y < aktueUerEditor->wch) 

&& (aktueUerEditor->zei lenptr[y])) 

aktueUerEditor->xposs x; 
aktueUerEditor‘>wdy = y; 
aktuellerEditor->ypos= 

aktuellerEditor->zeilennr[y]; 


case NEUSIZE: 

initUindouSize(aktuellerEditor); 

/* Pruefe, ob Cursor noch im Fenster! V 

if (aktuellerEditor->xpos > aktuellerEditor->leftpos 

‘•■aktuel lerEdi tor->wcw) 

aktuellerEditor*>xpos » aktuellerEditor->leftpos 
aktuel lerEdi tor*>wcw; 

if (aktuellerEditor*>wdy >» aktuellerEditor->wch) 
aktuellerEditor*>ypos * aktuellerEditor->zeilennr 
[(aktuellerEditor->wdy = aktuellerEditor->wch - 1)]; 

break; 

case REFRESHUINDOU: 

BeginRefresh(aktuellerEditor’>window); 

printAlK); 

EndRefresh(aktuellerEditor*>windou,TRUE); 
break; 

case CLOSEUINDOW: 
rurming = FALSE; 
break; 

default: 

printf("Nicht bearbeitbarer Event: Xlx\n",class); 

> /* of case */ 

> /* of while (GetMsgO) V 
> while (running); 
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Hinzugekommen ist außer den bereits besprochenen Dingen die 
Abfrage der MOUSEBUTTONS, so daß Sie den Cursor auch mit 
der Maus setzen können, wie Sie es von Textverarbeitungen ge¬ 
wöhnt sind. Während sich im Speicher-Modul nichts geändert 
hat, müssen wir im Ausgabe-Modul noch die Ausgabe der 
Faltenmarkierungen in einer anderen Farbe einbauen. Doch zu¬ 
erst eine neue globale Variable, die wir für printLine benötigen, 
um die letzte Spalte nicht mit auszugeben: 


^********************* 

* Globale Variablen: 

*★*******★★**★*★*★★★* j 


UUORD spaltenOec = 0; 


In der Funktion initWindowSize muß nun außer dem zeilenptr- 
Feld auch das zeilennr-Feld neu berechnet werden, wozu zwei 
zusätzliche Variablen definiert werden müssen: 


UWORD znr,*pnr; 

Die Berechnung des Feldes sieht nun wie folgt aus: 

/* Nun ggf. zeilenptr-Feld restaurieren; V 
if (newh != ed->wch) 

r 

if (newh < ed->wch) 

r 

/* Ueberfluessige Zeiger auf Null setzen: V 
zptr = ed->zeilenptr + newh +1; 
for (n = newh; n < ed->wch; n++) 

*zptr++ = NULL; 

> 

eise 

r 

zptr = ed->zeilenptr + ed->wch; 
z = *zptr++; 

pnr = &(ed->zeilennrCed->wch]); 
znr = *pnr++; 

for (n = ed->wch; n < newh; n++) 

r 

*zptr++ = (z = nextLine(z,&znr)); 

’*'pnr++ = znr; 

> 

> 

ed->wch = newh; 
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Auch die Funktion convertLineForPrint bleibt nicht von Ände¬ 
rungen verschont. Hier muß berücksichtigt werden, daß die 
Ausgabe nicht in der ersten Spalte beginnen kann, sondern in 
der Spalte, die durch leftpos bestimmt wird. 

Wir machen es uns jetzt einfach und setzen einen Zähler (skip) 
auf leftpos, und jedesmal, wenn wir ein neues Zeichen nach buf 
schreiben wollen, testen wir zuerst, ob skip bereits null ist. 

Ist dies der Fall, so wird das Zeichen geschrieben, andernfalls 
wird skip um eins vermindert. Wir überspringen damit die ersten 
skip-Zeichen: 

register DWORD skip = aktueUerEditor->leftpos; 

Die Bestimmung von lastchar bleibt gleich, aber die Konvertie¬ 
rung wird entsprechend geändert: 

/* Zeile konvertieren: */ 

tab = aktuellerEditor->tabstring; 
while ((len--) && (l < w)) 

if ((*buf = *zeile++) == TAB) 
do 
i 

tab++; 
if (skip) 
skip--; 
eise 
i 

1 ++; 

*buf++ = ' *; 

> 

> while ((*tab) && (l < w)); 
eise 
i 

tab++; 
if (skip) 
skip--; 
else 
C 


buf++; 


> 


> 
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Der Rest der Funktion bleibt unverändert. Als nächstes betrach¬ 
ten wir die Funktion printAt, an die zusätzlich zu den bisheri¬ 
gen Parametern noch die Zeichenfarbe übergeben werden muß. 
Diese ist entweder FGPEN oder FOLDPEN, und sie ist deswe¬ 
gen nötig, weil sonst nach einem Blank die Schriftfarbe nicht 
mehr stimmt, wenn es sich bei der Zeile um eine Faltenmarkie¬ 
rung handelt. Denn für Blanks muß die Vordergrundfarbe geän¬ 
dert und danach wieder zurückgesetzt werden: 

void printAt (buf,len,x,y,fgpen) 
regiSter UBYTE ‘buf; 

WORD len; 

register UWORD x.y; 

ULONG fgpen; 

Dementsprechend wird überall in dieser Funktion 

SetAPentrp,FGPEN); 


durch 


SetAPen(rp,fgpen); 

ersetzt. Die Funktion printLine wird nun noch so erweitert, daß 
sie Faltenmarkierungen erkennt und die Schriftfarbe dement¬ 
sprechend setzt. Dabei muß aber am Funktionsende wieder auf 
FGPEN geschaltet werden, damit wir uns an jeder beliebigen 
Stelle im Programm darauf verlassen können, daß die Vorder¬ 
grundfarbe FGPEN ist: 

void printLine (zeile,y) 

register struct Zeile *zeile; 
register UWORD y; 

i 

static UBYTE buf[MAXBREITE] ; 
register UWORD w; 
register struct Zeile *z; 
register ULONO pen; 

convertLineForPrint(zeile+1,zeile->len,w = 

aktuellerEditor->wcw,buf); 

/* Falls Anfang/Ende-Markierung einer Falte => FOLDPEN V 
if (zeile->flags & ZLF FSE) 
i 

if <(z = zeile->succ)->succ) 

C 
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if ((z->flags & ZLF FOLD) <= alctueUerEditor->inaxfold) 
i 

SetAPen(aktuellerEditor->rp,FOLDPEN); 
pen = FOLDPEN; 

> 

eise 

pen = FGPEN; 

> 

eise 

< 

SetAPen(aktuellerEditor->rp,FOLDPEN); 
pen = FOLDPEN; 

> 

printAt(buf,w - spaltenDec,aktuellerEditor->xoff,y,pen); 

/* Alte Schreibfarbe wieder einstellen: V 
if (pen != FGPEN) 

SetAPen(aktuellerEditor->rp,FGPEN); 

> 

eise 

printAt(buf,u - spaltenDec^aktuellerEditor*>xoff,y,FGPEN); 

> 

So, das war alles bezüglich des Ausgabe-Moduls. Fehlen nur 
noch die Änderungen in der Testumgebung, und wir können mit 
dem Testen beginnen. So muß die Zeilennummer, die von der 
Funktion print ausgegeben wird, nun aus dem zeilennr-Feld ge¬ 
holt werden: 

void printO 
C 

register struct Zeile 
regiSter DWORD n,*pnr; 

for (n = 0, 2 = aktuellerEditor*>zeilenptr, 
pnr = aktuellerEditor->zeilennr; 
n <= aktuel lerEdi tor->wch; m-i-, z++, pnr++) 
printf(”Zeile %d an Adresse X6lx.\n”,*pnr,*z); 

> 

In den Funktonen input und loesche_zeile sollte die Anzahl der 
Zeilen entsprechend angepaßt werden. Bei input, wenn die Ein¬ 
gabe erfolgreich war, mittels: 

aktuellerEditor->anz_ 2 eilen*+; 


und bei loesche zeile: 
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aktuellerEditor->anz_ 2 eilen--; 

Die Funktion init__zeilenptr muß nun zusätzlich die Falten-Level 
aller Zeilen bestimmen: 

void init zeilenptrO 
C 

register struct Zeile *z,**zptr; 
register UWORD n,*pnr,fold = 0; 

UWORD znr; 

for (z s aktuel lerEdi tor->zei len.head; z->slicc; z - z*>succ) 

< 

z->flags = <(z->flags & ''ZLF_F0LD) | (fold & ZLF^FOLD)); 
if (z->len >= 8) 

C 

if ((*((UL0NG *)(z+l))==V*#F*)&& 

(*((UL0NG *)(zi-1)+l)=='0LD:')) 
i 

folcH-+; 

z->flags 1= ZLF FSE; 

> 

if <<*<(UL0NG *)(z-H))==V*#E*)M 

(*((UL0NG *)(Z-H)+1)~*NDFD*)) 
i 

fold--; 

z->flags j= ZLF FSE; 

> 

> 

> 

for (n s 0, z - aktuellerEditor->zeilen.head, 
zptr s aktuellerEditor->zeilenptr, 
pnr = aktuellerEditor->zeilennr, znr =1; 
n < MAXHOEHE; 
i 

*zptr++ = z; 

♦pnr*»"»- = znr; 
z = nextLine(z,&znr); 

> 

> 

Die Abfrage auf Faltenmarkierung sieht zwar etwas "wild" aus, 
funktioniert aber, und zwar schneller als mit der String-Com- 
pare-Funktion aus der Standard-Bibliothek, da immer vier Zei¬ 
chen auf einmal miteinander verglichen werden (ULONG - 4 
Bytes). Im Moment handelt es sich ja eh noch um unsere Test¬ 
umgebung, da können wir uns solche Spielereien durchaus er¬ 
lauben. Später, wenn wir beliebige Strings als Faltenmarkierung 
zulassen, werden wir die Funktion strcmp oder strncmp verwen- 
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den, da dann nicht mehr sichergestellt ist, daß die entsprechende 
Zeichenkette genau acht Zeichen lang ist. 

Nachdem wir zu guter Letzt noch einen printAll-Aufruf an das 
Ende der Funktion Test gesetzt haben, der dafür sorgt, daß der 
Fensterinhalt stimmt, wenn wir die Testumgebung verlassen, 
sind wir mit unseren Umbauarbeiten fertig und können uns wie¬ 
der dem Testen widmen. Im Verzeichnis V0.4 finden Sie diesmal 
nicht nur die Quelltexte und den compilierten Editor, sondern 
auch eine Testdatei namens TestText. Starten Sie den Editor mit: 

Editor <TestText 

Dann sparen Sie sich das mühselige Eingeben der einzelnen Zei¬ 
len. Wenn die Datei geladen ist, wird die Testumgebung auto¬ 
matisch verlassen, da die Teistdatei mit dem ESCAPE-Zeichen 
endet, und Sie können den Editor ausgiebig ausprobieren, inklu¬ 
sive Folding, da im Testtext auch einige Falten definiert sind. 

Nun sollten wir uns so langsam mit dem Debugger vertraut ma¬ 
chen, damit wir ihn im Falle eines Falles auch optimal einsetzen 
können. Zu diesem Zweck folgende Übungsaufgabe: Es soll die 
tatsächliche Y-Position des Cursors ausgegeben werden, und 
zwar vom Debugger. 

Zuerst compilieren wir den Editor erneut, aber diesmal, indem 
wir "make Debug" auf rufen. Die Make-Datei sorgt dann dafür, 
daß das fertige Programm auch Informationen über die Vari¬ 
ablennamen, also eine sogenannte Symboltabelle enthält. Diese 
erleichtert uns das Auf finden von bestimmten Stellen des Pro¬ 
gramms ganz erheblich. Nach dem Compilieren starten wir den 
Debugger mit: 

SYS3:bin/clb 

Dieser lädt eine Datei namens .dbinit, in der meist nur der Be¬ 
fehl al steht. Wartet der Debugger nach dem Starten nicht da¬ 
rauf, daß Sie einen neuen Task starten, was in der Infozeile des 
Debugger-Fensters angezeigt wird, so müssen Sie al eingeben. 
Dann starten Sie den Editor, wie Sie es zuvor zum Ausprobieren 
getan haben. Der Debugger merkt, daß ein neues Programm ge- 
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startet wurde, und fängt dieses ab. Dann Oberprüft er, ob das 
Programm auch eine Symboltabelle enthält und lädt diese gege¬ 
benenfalls. 

Nachdem alles erfolgreich geladen worden ist, zeigt der Debug¬ 
ger den ersten Befehl an, in unserem Fall: 

jmp .begin 

Wir wollen den Debugger nun dazu bringen, die Y-Position des 
Cursors anzuzeigen. Da dies nur dann notwendig ist, wenn sich 
diese geändert hat, lassen wir diese anzeigen, nachdem der Be¬ 
nutzer den Cursor bewegt hat. Und wo wird der Cursor bewegt? 
In den Funktionen cursorUp und cursorDown. Zwar gibt es noch 
ein paar andere Stellen, aber fürs erste wollen wir uns mit die¬ 
sen beiden bescheiden. Um die Y-Position ausgeben zu können, 
müssen wir wissen, an welcher Speicherposition diese liegt. Wir 
wissen, daß die Y-Position Element der Editor-Struktur ist, und 
wir wissen, daß sie von den Funktionen cursorUp und cursor¬ 
Down geändert wird. Folglich sehen wir uns diese Funktionen 
genauer an. Geben Sie dem Debugger folgende Anweisung: 

u cursorUp 

Der Debugger zeigt nun den Speicher in disassemblierter Form 
ab der Adresse cursorUp an, also ab dem Anfang unserer Funk¬ 
tion cursorUp. Bei uns sah dies wie folgt aus: 


_cursorUp 

~cursorUp<-4 

__cursorUp+8 

_cursorUp+c 

_cursorUp+e 

_cursorUp^12 

_cursorUp<-16 

_cursorUp*-18 

_cur8orUp«-1c 

_cursorUp**20 

_cur8orUp<*24 

_cur8orUp«-28 

~cur8orUp4‘2a 

~cur8orUFH-2c 

_cur8orUpf2e 

"cur8orUp+32 

_cur8prUp<'36 

_cur8orUp<'38 


link 

a5,#-2 

movea.l 

aktuellerEdltor,aO 

t8t.W 

252(a0) 

beq.8 

_cur8orUp4-18 

movea.l 

ak t ue 11 erEd i t or, aO 

8ubq.w 

#1,252(a0) 

bra.8 

cur8orUp«'40 

pea 

-2<a5) 

movea.l 

_aktuellerEditor,aO 

move.l 

ca(a0),’(a7) 

jar 

jprevLine 

addq.w 

#8,a7 

tat.l 

dO 

beq.8 

cur8orUp«'3a 

move.w 

#1.-<a7) 

jsr 

8croll0own 

addq.w 

i2,a7 

bra.8 

_cur8orUp*-40 
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_cursorUp<-3a 

moveq 

#0,d0 

__cursorUp+3c 

unlk 

a5 

__cursorUp+3e 

rts 


_cursorUp+40 

movea.l 

aktuellerEditor 

_cursorUp<*44 

moveq 

#0,d0 

_cursorUp<'46 

move.u 

252(a0),d0 

_cursorUp+4a 

asl. l 

#1,d0 

_cursorUp+4c 

movea.l 

d0,a1 

_cursorUp+4e 

adda.l 

_aktuellerEditor 

_cursorUp+52 

movea.l 

^aktuellerEditor 

__cursorUp*56 

move.w 

Tca(a1),250(a6) 

__cursorUp+5c 

moveq 

#1,d0 

_cursorUp4-5e 

bra.s 

_cursorUp^3c 


Sie wissen ja noch, daß die Y-Position aus dem Feld zeilennr 
geholt worden ist. Wir suchen also ein Programmstück, in dem 
zuerst auf ein Feld zugegriffen wird und dann ein Wert in ein 
Element der Editor-Struktur geschrieben wird. Dieses Stück fin¬ 
den wir ab Adresse _cursorUp+40: Zuerst wird nach AO ein 
Zeiger auf die aktuelle Editor-Struktur gebracht. Dann wird DO 
mit wdy geladen und dieses als Index für das zeilennr-Feld be¬ 
nutzt (deswegen die Multiplikation mit zwei (ASL)). Ab Adresse 
_cursorUp+56 wird dann der Wert aus dem Feld in die Variable 
ypos geschrieben. Das bedeutet, daß ypos 250 (hex) Bytes vom 
Anfang der Struktur entfernt ist. 

Um herausfinden zu können, welche Variable in C durch welche 
Speicherstelle in Assembler repräsentiert wird, brauchen Sie al¬ 
lerdings etwas Erfahrung in Assembler. Eine andere Möglichkeit, 
an diese Werte zu kommen, besteht darin, in der Editor-Struktur 
die Elemente entsprechend ihres Platzbedarfs in Bytes abzuzäh¬ 
len. Nachdem wir nun wissen, wo ypos steckt, müssen wir uns 
eine Stelle überlegen, an die wir den Breakpoint setzen, der da¬ 
für sorgt, daß die Y-Position ausgegeben wird. Nachdem die Y- 
Position geändert worden ist springt, das Programm an die 
Adresse _cursorUp+3c. An dieser Adresse steht ein UNLK-Be- 
fehl, mit dem alle Unterprogramme in C enden (zumindest beim 
Aztec). An diese Adresse setzen wir auch den Breakpoint: 

bs cursorUp+3c ;pd 250+*aktueUerEditor;g 

Das pd bedeutet Print Decimal; der Debugger soll den Inhalt der 
angegebenen Speicherstelle dezimal ausgeben. Die Speicherstelle 
entspricht der Y-Position des aktuellen Editors, also 250 Bytes 
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hinter der Adresse, auf die aktuellerEditor zeigt. Das g bedeutet, 
daß der Debugger den Editor sofort wieder starten soll. Wir 
wollen den Editor ja nicht wirklich unterbrechen, sondern nur 
die Y-Position ausgegeben haben. Den nächsten Breakpoint set¬ 
zen wir in das Unterprogramm cursorDown, und zwar auch wie¬ 
der ans Ende. Geben Sie also: 

u cursorDown 

ein, und suchen Sie den UNLK-Befehl, indem Sie solange u 
eingeben, bis Sie ihn gefunden haben. In unserem Fall lag er an 
Adresse _cursorDown+66. Setzen Sie den Breakpoint wie gehabt: 

bs cursorDown+66 ;pd 250’»'*alctueUerEditor;g 

Damit wären unsere Vorbereitungen beendet, und wir können 
den Editor mittels g (Go) starten. Alles verläuft zunächst ganz 
normal... bis Sie CursorUp (also die Taste auf der Tastatur) 
drücken. Dann wird das Debugger-Fenster nach vorne geholt, 
aktiviert, und der Editor wird sofort wieder gestartet, was Sie 
daran sehen, daß der Cursor im Debugger-Fenster nicht hinter 
einem Fragezeichen steht. Die Sache hat nur einen Haken: Das 
Editorfenster ist nicht mehr vorne und, was schon tragischer ist, 
nicht mehr aktiviert! 

Verkleinern Sie das Debugger-Fenster nun so, daß es das Edi¬ 
torfenster nicht mehr stört, aber noch groß genug ist, daß die 
Y-Position ausgegeben werden kann. Das Editorfenster ver¬ 
größern Sie analog soweit, daß man das Debugger-Fenster noch 
ganz sehen kann. Nun aktivieren Sie das Editorfenster wieder, 
indem Sie entweder den Fensterrahmen oder direkt den Cursor 
anklicken; in allen anderen Fällen würde ja der Cursor an eine 
andere Position gesetzt werden. 

Sie müssen nun jedesmal, nachdem Sie CursorUp oder Cursor¬ 
Down gedrückt haben, das Editorfenster wieder aktivieren, mit 
anderen Worten: reaktivieren. Das ist zwar unschön, aber erträg¬ 
lich. Bewegen Sie den Cursor nun über ein paar Zeilen, auch 
über Falten, und prüfen Sie, ob die angezeigte Position plausibel 
ist. Gehen Sie auch in Falten hinein, und scrollen Sie ein wenig. 
Wenn Sie davon genug haben, so gehen Sie wieder an den Text- 
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anfang, und prüfen Sie, ob dieser immer noch die Zeilennummer 
Eins hat. Sie werden dabei sehr wahrscheinlich feststellen, daß 
dies nicht der Fall ist, aber vielleicht ist Ihnen bereits aufgefal¬ 
len, daß in der Berechnung der Y-Position noch ein Fehler 
steckt. 

Überlegen wir uns dazu, bei welcher Gelegenheit der Fehler 
auf getreten ist: Solange wir im Fenster blieben und in keine 
Falten eingetreten sind, hat alles noch tadellos funktioniert. Das 
ist kein Wunder, da die Zeilennummern in dem Feld zeilennr 
abgelegt waren. Erst als diese geändert werden mußten, trat der 
Fehler auf. Dies bedeutet zumindest, daß es an der Funktion 
nextLine, die die Zeilennummern berechnet hat, wahrscheinlich 
nicht liegt, da sie ja die Zeilennummern initialisiert hat. Nun 
gibt es zwei Möglichkeiten zur Fehlersuche: Entweder man 
schaut sich den Quelltext ein paarmal scharf an, oder man testet 
so lange alle Möglichkeiten aus, bis der Fehler soweit eingekreist 
ist, daß man schon ziemlich genau sagen kann, an welcher Stelle 
dieser liegt. 

Wir werden es zuerst mit scharfem Hinsehen versuchen. Laden 
Sie dazu das Modul Cursor.c in einen Editor, und sehen Sie sich 
die Programmstelle an, an der das Folding bewerkstelligt wird. 
Sie werden vermutlich keinen Fehler entdecken können; zumin¬ 
dest konnten wir keinen finden, aber das will ja nichts heißen. 
Was haben wir noch beim Testen getan? Gescrollt! Sehen Sie sich 
also die Funktionen scrollUp und scrollDown an. Diese scheinen 
jedoch auch keinen Fehler zu enthalten. Bevor wir endlos testen, 
werfen wir noch einen Blick auf die Funktion prevLine, die von 
der Funktion scrollDown benutzt wird. Wenn Sie genau hinse- 
hen, so bemerken Sie, daß in dieser Funktion die Zeilennummer 
ebenso wie in nextLine um Eins erhöht wird (*pnr++), statt um 
Eins vermindert zu werden (*pnr—). 

Ändern Sie dies, speichern Sie die Datei ab und lassen den Edi¬ 
tor erneut compilieren. Der Editor im Verzeichnis V0.4 hat üb¬ 
rigens auch diesen Fehler, damit Sie daran den Debugger aus¬ 
probieren können. Ist der Fehler behoben, können Sie den Editor 
erneut testen, so Sie Lust dazu haben. 
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4.3.8 Texteingabe 

Im folgenden wollen wir den Editor einsatzfähig machen. Wir 
werden Funktionen einbauen, die es uns ermöglichen, einen Text 
zu editieren. Dazu brauchen wir Funktionen, die es uns erlau¬ 
ben, Zeichen einzugeben und zu löschen. Ferner müssen sich 
auch Zeilen einfügen und löschen lassen. Überlegen wir uns 
nun, wie diese Funktionen arbeiten sollen. 

Vor dem Einfügen von Zeichen muß die entsprechende Zeile in 
den Puffer der Editor-Struktur kopiert werden, so sie sich noch 
nicht dort befindet. Dann werden alle Zeichen nach hinten ge¬ 
schoben, die unterhalb oder rechts vom Cursor stehen, und das 
neue Zeichen unterhalb des Cursors eingefügt. Allerdings gilt 
dies nur für den Einfügemodus. Befindet sich der Editor im 
Überschreibmodus, so wird das Zeichen einfach nur in den Text 
geschrieben. Das Zeichen, daß sich zuvor dort befand, wird da¬ 
durch gelöscht. Anschließend wird der Cursor noch um eine 
Stelle nach rechts bewegt. Dabei gilt es zu beachten, das keine 
Zeichen rechts aus der Zeile herausgeschoben werden. In einem 
solchen Fall wird das Zeichen nicht eingefügt, statt dessen lassen 
wir den Bildschirm zur Warnung einmal blinken. 

Eine Sonderstellung beim Einfügen nehmen die Sonderzeichen 
ein, namentlich CR (Carriage Return = 13), LF (Line Feed = 
10), BS (Back Space = 8), DEL (Delete = 127) und TAB (Tabu¬ 
lator = 9). Bei CR und LF muß die Zeile an der Cursor-Position 
aufgesplittet und eine neue Zeile eingefügt werden. Bei BS und 
DEL werden dagegen Zeichen gelöscht, wobei bei BS auch noch 
berücksichtigt werden muß, ob sich der Editor im Einfüge- oder 
Überschreibmodus befindet (aktuellerEditor->insert), ebenso wie 
beim Einfügen von Zeichen. Bei TAB werden, abhängig von der 
Cursor-Position, gleich mehrere Zeichen eingefügt. 

Überhaupt müssen wir uns bei Tabulatoren so langsam darauf 
einigen, wie wir sie behandeln. Bei der Cursor-Positionierung 
wollten wir uns ja nicht von diesen stören lassen, also liegt es 
nahe, daß wir dies auch nicht beim Editieren tun. Stellt sich 
aber die Frage, wie wir unseren Text mit Tabulatoren formatie¬ 
ren. Da wir mit unserem Editor vorwiegend Programmtexte ein- 
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geben wollen, bei denen es meist egal ist, ob und wie wir diese 
formatieren (der Aztec Oberliest Tabulatoren genauso wie 
Blanks), können wir folgendermaßen vorgehen: 

Wenn wir eine Zeile in den Puffer kopieren, wandeln wir 
alle Tabulatoren in eine entsprechende Anzahl von Blanks 
um, so wie wir es bereits bei der Funktion convertLine- 
ForPrint getan haben. 

Soll die Zeile wieder aus dem Puffer zurück in die Zeile 
geschrieben werden, so wandeln wir alle Blanks wieder in 
Tabulatoren um, soweit dies möglich ist. 

Somit haben wir stets eine Formatierung mit möglichst geringem 
Platzbedarf. Der einzige Nachteil dieser Methode ist, daß wir 
Tabulatoren nicht gezielt bzw. nicht mehrere Blanks hinterein¬ 
ander setzen können, die wirklich auch als Blanks abgespeichert 
werden statt als Tabulatoren. Diesem können wir abhelfen, in¬ 
dem wir ein Flag namens aktuellerEditor->tabs einführen. Ist 
dieses auf Eins gesetzt, so werden Blanks möglichst optimal in 
Tabulatoren umgewandelt, andernfalls werden Tabulatoren bei 
der Aus- und Eingabe als ganz normale Sonderzeichen behandelt 
(Ctrl-I), und es wird keine Konvertierung vorgenommen. 

Nun müssen wir den Puffer irgendwann wieder in die Zeile- 
Struktur zurückschreiben. Dies tun wir genau dann, wenn wir 
mit dem Cursor die aktuelle Zeile verlassen. Zu diesem Zweck 
schreiben wir eine Funktion, die aus der Hauptschleife des Edi¬ 
tors jedesmal aufgerufen wird, nachdem eine Message bearbeitet 
wurde, und die den Pufferinhalt in die Zeile zurückschreibt, 
falls der Cursor diese Zeile verlassen hat. Wir brauchen also 
noch eine Variable namens pufypos, die die Zeilennummer der 
Zeile enthält, die sich gerade im Puffer befindet, bzw. die Null 
ist, falls sich keine Zeile im Puffer befindet. Auf die Zeile- 
Struktur der Zeile, die sich im Puffer befindet, zeigt die Va¬ 
riable aktuell der Editor-Struktur, die wir als Indiz dafür neh¬ 
men, ob sich gerade eine Zeile im Puffer befindet. Wir dürfen 
übrigens nicht vergessen, das Flag ZLF_USED in der Zeile- 
Struktur zu setzen, wenn wir eine Zeile in den Puffer kopieren. 
Dieses Flag brauchen wir, um bei der Ausgabe festzustellen, ob 
sich eine Zeile gerade im Puffer befindet. 
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Damit können wir nun die Funktionen konzipieren, aus denen 
sich unser neues Modul "Edit" zusammensetzen wird: 

void getLineForEdit(ze1 le,zeilermuniner) 
struct Zeile *zeile; 

UWORD zeilennummer; 

Diese Funktion kopiert die Zeile zeile in den Puffer und setzt 
alle entsprechenden Variablen. Zum Konvertieren verwenden 
wir die Funktion convertLineForPrint, da diese ohnehin genau 
das macht, was wir benötigen. Freilich müssen wir aktueller- 
Editor->leftpos vorher auf Null setzen, damit auch wirklich alle 
Zeichen konvertiert werden und später wieder den ursprüngli¬ 
chen Wert zurückschreiben. Allerdings müssen wir diese Funk¬ 
tion noch etwas erweitern, da wir die Länge der konvertierten 
Zeile benötigen, die wir in aktuellerEditor->puflen abspeichern, 
und da wir auch lastchar kennen müssen, das wir uns in aktuel- 
lerEditor->puflastchar merken. Beim Löschen von Zeichen muß 
nämlich das letzte Zeichen im Puffer durch lastchar ersetzt wer¬ 
den, damit diese auch korrekt aussieht, wenn wir die Zeile auf 
dem Bildschirm ausgeben. 

BOOL saveLineCzeile) 
struct Zeile *zeile; 

Speichert die im Puffer befindliche Zeile wieder in die Zeile- 
Struktur ab, auf die aktuellerEditor->aktuell zeigt. Dabei muß 
eventuell eine neue Zeile beschafft werden, falls die Länge der 
ursprünglichen Zeile von der neuen Länge abweicht. Falls die 
alte oder die geänderte Zeile eine Faltenmarkierung darstellt, so 
müssen gegebenenfalls die Level aller folgenden Zeilen entspre¬ 
chend angepaßt werden. Falls, aus welchem Grund auch immer, 
die Zeile nicht zurückgeschrieben werden konnte, so gibt die 
Funktion FALSE zurück. 

void saveIfCursorMoved() 

Diese Funktion wird in der Hauptschleife des Editors nach der 
Abarbeitung jeder Message aufgerufen. Stellt diese Funktion 
fest, daß der Cursor die aktuelle Eingabezeile verlassen hat, so 
ruft sie die Funktion saveLine auf. 
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Die folgenden Funktionen stellen die eigentlichen Funktionen 
zur Textbearbeitung dar. Dadurch, daß diese als einzelne Funk¬ 
tionen implementiert werden, läßt sich später eine Kommando¬ 
sprache um so einfacher realisieren, da die einzelnen Befehle 
einfach nur die entsprechenden Funktionen auf rufen. Jede dieser 
Funktionen gibt FALSE zurück, falls die Funktion nicht ausge¬ 
führt werden konnte. 

BOOL undoLineO 

Wenn sich eine Zeile im Puffer befindet, so werden alle Ver¬ 
weise gelöscht, und die ursprüngliche Zeile wird wieder sichtbar 
gemacht. 

BOOL deleteCharO 

Löscht das Zeichen unter dem Cursor und schiebt den rechten 
Rest der Zeile um ein Zeichen nach links. Dies geschieht im 
Programm beim Drücken der Delete-Taste. 

BOOL backspaceChart) 

Löscht das Zeichen links vom Cursor und schiebt den rechten 
Rest der Zeile um ein Zeichen nach links, wenn der Editor im 
Einfügemodus arbeitet. Andernfalls wird einfach nur ein Blank 
links vom Cursor über den Text geschrieben. Der Cursor wird 
um eine Position nach links gesetzt. 

BOOL insertChar(c) 

UBYTE c; 

Fügt das Zeichen c an der Cursor-Position in den Text ein, 
wenn sich der Editor im Einfügemodus befindet. Arbeitet der 
Editor dagegen im Überschreibmodus, so wird das Zeichen unter 
dem Cursor durch das neue Zeichen ersetzt. Diese Funktion be¬ 
arbeitet auch die Tabulatoren. 

BOOL insertLine(c) 

UBYTE c; 

Diese Funktion trennt die aktuelle Zeile an der momentanen 
Cursor-Position auf und fügt eine neue Zeile in den Text ein. 
Das Zeichen c ist entweder CR oder LF, je nachdem, welche 
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Taste gedrückt worden ist. Der Cursor wird auf den Anfang der 
nächsten Zeile gesetzt. 

In diese Funktion bauen wir Auto-Indent ein. Auto-Indent be¬ 
deutet, daß der Cursor nach Drücken von Return nicht in der 
ersten Spalte der neuen Zeile steht, sondern unter dem ersten 
Zeichen der darüber liegenden Zeile. Dies gilt auch dann, wenn 
eine Zeile durch Return aufgesplittet wird und sich der Cursor 
mitten in der Zeile befand. Über das Flag autoindent der Edi¬ 
tor-Struktur kann man Auto-Indent auch abschalten. 

BCX)L deleteLineO 

Löscht die Zeile, in der sich der Cursor befindet. Aufpassen 
muß man hierbei, wenn man sich in einer Falte befindet, die am 
Textende steht. Löscht man hier alle Zeilen, so kommt es dazu, 
daß noch weitere Zeilen existieren, diese aber nicht auf dem 
Bildschirm dargestellt werden, da deren Falten-Level außerhalb 
von minfold und maxfold liegen. In diesem Fall vermindert 
diese Funktion minfold solange, bis eine Zeile gefunden wird, 
die dann auch in der obersten Zeile des Fensters angezeigt wird. 
Ansonsten arbeitet die Funktion so, daß sie versucht, den Cursor 
auf der aktuellen Position zu lassen, das heißt, daß normaler¬ 
weise der untere Teil des Fensterinhalts nach oben gescrollt 
wird, nachdem die Zeile gelöscht worden ist. Aber das Scrolling 
ist ohnehin eine Sache für sich, weswegen wir es auch erst nach 
der Auflistung der Funktionen erläutern werden, damit Sie sich 
dies dann anhand des Programmtextes vor Augen führen können. 

Auf gerufen werden alle genannten Funktionen von der Funktion 
handleKeys aus, die wir ja bereits für die Cursor-Steuerung 
verwendet haben. Hier nun der Quelltext unseres neuen Moduls: 

<src/Edit.c> 

^************ 

★ 

* Includes: 

* 

************ f 

#include <exec/types.h> 

# 1 nclüde <intuition/rntuition-h> 
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#include *'src/Editor.h" 

y*********** 

* 

♦ Defines: 

* 

*********** j 

#define CR 13 
#ciefine LF 10 
#define TAB 9 

/* Laenge von Foldanfang und -ende: V 
#define FSE^LEN 10 

/* Anzahl Zeichen, die signifikant fuer Faltenmarkierung sind: V 
#define FSE^SIG 8 

y********************** 

* 

* Externe Funktionen: 

* 

**********************! 

UWORD convertLineForPrint(),strncmpC),recaIcTopOfWindow(); 
void loescheZeile(),Insert(),printAll(),restoreZeilenptr(); 
void DisplayBeep(),printLine(),AddHead(),scro11Right(),scro11Up(); 
void ScrollRasterO; 

struct Zeile *neueZeileO^^nextLineO^^prevLineO^- 

BOOL cursorLeft(),cursorRight(),cursorDown(),cursorHomeC); 

y********************* 

* 

* Externe Variablen: 

* 

********************* j 

extern struct Editor ♦aktuellerEditor; 

y********************* 

* 

* Globale Variablen: 

* 

********************* y 

UBYTE foldAnfangn = "/’*#FOLD:V"; 

UBYTE foldEndeC] = *V*#ENDFDV"; 

^*************** 

* * 

* Funktionen: * 

* * 


*************** y 
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* 

* getLineForEdit( 2 eile,znr) 


* Kopiert Zeile zum Editieren 

* in den Puffer. 

* 


* Zeile “ Zeile. 

* znr = Zeilennummer der Zeile. 

* 

********************************^ 


Yoid getLineForEdit (zeile^znr) 
register struct Zeile *zeile; 
regiSter UUORD znr; 

i 

register UWORD leftpos; 

/* Leftpos retten: */ 

leftpos = aktuellerEditor->leftpos; 

aktuellerEditor->leftpos = 0; 

/* Zeile konvertieren: */ 
aktuellerEditor->puflen = 

convertLineForPrint(zeile+1,zeile->len,MAXBREITE + 1, 
aktuellerEditor*>puffer,iaktuellerEditor*>puflastchar); 

/* Zeile als “benutzt” markieren: V 
zeile->flags |= ZLF_USED; 
aktuellerEditor->aktuell = zeile; 
aktuellerEditor‘>pufypos = znr; 

/* Leftpos wieder Herstellen: V 
aktuellerEditor'>leftpos = leftpos; 


y******************************* 


* cursorOnText: 

* 


* Stellt sicher, dass sich der 

* Cursor auf Text befindet. 




void cursorOnTextO 
L 

register struct Zeile **zptr; 
register UWORD l; 

/* Sicherstellen, dass Cursor auch wirklich auf Text steht: V 
zptr = &(ZEILENPTR(l = aktuellerEditor->wdy)); 
while ((*zptr == NULL) && l) 

C 
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zptr--; 

1 -; 

> 

aktueUerEditor“>wdy = l; 
aktueUerEditor->ypos = ZEILENNR(l); 


^***4r**********4r********** 

Sr 

* deconvertLineO: 


* Dekonvertiert Zeile. 

* 


* buf “ Ziel-Puffer. 

* puffer“ Quell-Puffer. 

* puflen= dessen Laenge. 

Sr 

SrSrSrSr*SrSrSrSrSrSr*SrSrSrSrSrSrSr*Sr*SrSrSr j 


UWORD deconvertLine(buf, puffer,puflen) 

UBYTE *buf,*puffer; 

UWORD puflen; 

register UBYTE *p1,*p2,*tab,*fb = NULL; 
regiSter WORD l; 

/* Zeile dekonvertieren: V 
p1 = puffer; 
p2 = buf; 

tab= aktuellerEditor->tabstring; 
l = puflen; 

if (aktuellerEditor->tabs) 

Blanks wieder in Tabulatoren verwandeln: V 
while (l) 

L 

if ((*p2 = *p1++) == ' *) 

C 

if (fb == NULL) 
fb = p2; 

> 

eise 

< 

if (fb) 

fb = NULL; 

> 


/* fb zeigt auf erstes Blank, sofern seitdem keine V 
/* anderen Zeichen kopiert worden sind, (first blank) V 
if ((! ♦-►-»•tab) && (fb)) 

C 

*fb = TAB; 
fbf+; 
p2 = fb; 
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> 

eise 

p2++; 

> 

eise 

while (l) 

< 

*p2 = *p1; 

p1++; 

p2++; 

> 

/* Blanks am Ende loeschen: V 
if (aktuellerEditor*>skipblanks) 

Hhile <<p2 > buf) && ((*(p2-1) == • •) || (*(p2-1) == TAB))) 

p2-; 

return ((DWORD)(p2 - buf)); 


y**************************************** 

* 

* getFoldInc(zeile) 

* 

Bestimmt, ob Zeile eine Faltenanfangs- 

* oder ‘Endemarkierung ist und gibt 

* dementsprechend 1 oder *1 zurueck. 

* Andernfalls wird 0 zurueckgegeben. 

* 

* Zeile “ entsprechende Zeile. 

* 

DWORD getFoldInc(zeile) 
struct Zeile *zeile; 

regiSter DBYTE *p1; 
regiSter DWORD l; 

/* Faltenmarkierung am Anfang einer Zeile! */ 
p1 * (DBYTE ♦)(zeile + 1); 
l * zeile->len; 

while (l && ((*p1 == • ') jj (*p1 == TAB))) 
i 

i--; 

> 


/* Bestimme Art der Faltenmarkierung (-> l): V 
/* 1 = Anfang, */ 
/* -1 = Ende und V 
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0 = keine Faltenmarkierung. V 

if (l >= FSE_.SIG) 

if (strncmpCpl ,folclAnfang,FSE SIG) == 0) 

1 = 1; 

eise if (strncmp(p1,foldEnde,FSE SIG) == 0) 
l = -1; 

else 
l = Gl¬ 
eise 

l = 0; /* keine Faltenmarkierung V 
return (l); 


^******************************* 

* 

* saveLineCzeile) 

* 

* Speichert Zeile wieder ab. 


* Zeile * alte Zeile*Struktur. 

* 

******************************* y 


BCX)L saveLine(Zeile) 
struct Zeile *zeile; 
i 

static UBYTE bufCMAXBREITE ♦ 2]; /* +2 fuer CR und LF V 

register UBYTE *p1,*p2,*tab,*fb = NULL; 

regiSter WORD l,len; 

struct Zeile *pred,*old,**zptr; 

/* Nur zur Sicherheit: V 
if (aktuellerEditor->aktuell == NULL) 
return (FALSE); 

/* Zeile dekonvertieren: V 

p2 = buf ♦ (len = deconvertLine(buf,aktuellerEditor->puffer, 

aktuellerEditor->puflen)); 

/* Stelle fest, ob Zeile durch CR oder LF beendet, */ 

/* und erhoehe len entsprechend. V 
p2 = buf + len; 
if (l = zeile->len) 
i 

p1 = ((UBYTE *)(zeile D) zeile->len - 1; 
if (*p1 == CR) 
i 

len+-*-; 

*p2 = CR; 

> 

eise if (*p1 == LF) 
i 


len++; 
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if (d > 1) && (*--p1 == CR» 

{ 

len++; 

*p2++ = CR; 

> 

*p2 = LF; 

> 

> 

/* ggf. neue Zeile beschaffen: */ 
if (EVENLEN(len) EVENLEN(zeile’>len)) 

C 

old = Zeile; 

if (Zeile = neueZeile(len)) 
i 

Insert(&aktuellerEditor->zeilen,zeile,old); 
zeile->flags = old->flags & ‘'ZLF_USED; 
loescheZeile(old); 

/* Nun eventuelle Zeiger Umsetzern */ 
for (1=0, zptr = aktuellerEditor->zeilenptr; 
l <= aktuellerEditor->wch; 1++, zptr-»-+) 
if (*zptr == old) 

♦zptr = Zeile; 
break; 

> 

> 

eise 

return (FALSE); 

> 

eise 

< 

zeile->len = len; 
zeile->flags &= ''ZLF^USED; 


/* Zeile zurueckschreiben: V 
p1 = (UBYTE *)(zeile + 1); 
p2 = buf; 
l = len; 

while (l) 

< 

*p^ = ♦pZ; 

pi+^; 

p2++; 

l--; 


/♦ Folding ggf. rekonstruieren: ♦/ 

/* War alte oder ist neue Zeile eine Faltenmarkierung? V 
l = getFoldlnc(zeile); 
if ((zeile->flags & ZLF_FSE) || l) 
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i 

/* Zunaechst das ZLF FSE-Flag entsprechend l setzen: V 
if (l) 

zeUe->flags |= ZLF^FSE; 
eise 

zeile->flags &= “ZLF^FSE; 

/* Bestimme nun, wie der Falten-Level der nachfolgenden */ 
/* Zeilen geändert werden muß: level += l. V 

if ((old = zeile->succ)->succ) 
i 

if (((zeile->flags+1) & ZLF^FOLD) == 

(old->flags & ZLF^FOLD)) 

/* Alte Zeile war Faltenanfang: V 

l -= 1; 

else if ((zeile‘>flags &ZLF_FOLD)== 

((old->flags+1) &ZLF_^FOLD)) 

/* Alte Zeile war Faltenende: V 

l += 1; 

if (l) 

/* Falten-Level aller folgender Zeilen ändern: V 
while (old’>succ) 
i 

old->flags = (old->flags & "ZLF FOLD) 

1 ((old->flags + l) & ZLF^FOLD); 
old = old->succ; 

> 

restoreZei lenptrO; 
printAll(); 
cursorOnTextO; 

> 

> 

> 

/* Zeile zur Sicherheit ausgeben: V 
/* Zuerst Ypos bestimmen: V 

for (1=0, zptr = aktuellerEditor->zeilenptr; 
l <= aktuellerEditor->wch; l-*-«»*, zptr-*"*-) 
if (*zptr == Zeile) 

< 

printLine(zeile,aktuellerEditor->yoff ♦ 

aktuellerEditor->ch*l); 

break; 

> 

/* Verweise loeschen: */ 
aktuellerEditor->aktuell = NULL; 
aktuellerEditor->puflen = 0; 
aktuellerEditor->pufypos = O; 
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/* Text wurde veraendert! V 
aktuellerEditor->changed = 1; 

return (TRUE); 

> 


^4r4r************************************* 

★ 


* saveIfCursorMoved: 

* 


* Speichert Zeile im Puffer wieder ab, 

* falls der Cursor bewegt worden ist. 

* 


***************************************y 


void saveIfCursorHovedO 
C 

regiSter UUORD pufypos; 


> 


if (pufypos = aktuellerEditor->pufypos) 
if (aktuellerEditor->ypos != pufypos) 

if (! saveLine(aktuellerEditor->aktuell)) 
DisplayBeep(NULL); 


y4r4r*4r4r*4r4r*4r**4r4r*4r4r*****4r****4r**4r********4r** 

♦ 

* undoLine: 

* 

* Macht die Aenderungen in der aktuellen 

* Zeile wieder rueckgaengig, sofern 

* der Cursor diese noch nicht wieder 

* verlassen hat. 

* 


******************************************y 


void undoLineO 
C 

register struct Zeile *z; 


if (ZS aktuellerEditor’>aktuell) 

C 

aktuellerEditor->aktuell = NULL; 
aktuellerEditor->pufypos > 0; 
aktuellerEditor’>puflen = 0; 

z->flags &= “ZLF^USED; 


> 


I* Zeile ausgeben: V 

print Line(z,aktue11erEditor->yoff 

♦ aktuellerEditor->ch*aktuellerEditor->wdy); 


> 
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* getPufferPointer(pptr,pinc,prest): 

* 


* Initialisiert Zeiger auf aktuellerEditor->puffer. 

* Der Puffer wird ggf. initialisiert. 

* Gibt FALSE zurueck, falls Puffer nicht 

* initialisiert werden konnte. 

* 

* pptr “ Zeiger in Puffer auf Cursor-Position. 

* pinc * Offset vom Pufferanfang. 

* prest" puflen - inc. 

* 

**********4r*********ar******************************^ 


BOOL getPufferPointer(pptr,pinc, prest) 

UBYTE **pptr; 

UWORD *pinc,*prest; 

< 

regiSter UBYTE *ptr; 
regiSter WORD inc,rest; 

/* Puffer ggf. initialisieren: V 
if (aktuellerEditor->aktuell == NULL) 
i 

regiSter UWORD wdy; 

if <ZEILENPTR(wdy = aktuellerEditor->wdy)) 

getLineForEdit(ZEILENPTR(wdy),ZEILENNR(wdy)); 

eise 

if (aktuellerEditor->anz Zeilen == 0) 

< 

/* Erzeuge allererste Zeile: V 
regiSter struct Zeile *z; 

if (z = neueZeile((UWORD) 1)) 
i 

*((UBYTE *)(z + D) = LF; 

AddHead(&aktuellerEditor’>zeilen,z); 

ZEILENPTR(O) = z; 

ZEILENNR(O) = (aktuellerEditor->anz Zeilen = 1); 
getLineForEdit(ZEILENPTR(0),ZEILENNR(0)); 

> 

eise 

return (FALSE); 

> 

eise 

/* Cursor steht nicht auf Zeile! V 
return (FALSE); 

> 


/* Bestimme Zeiger auf Cursor-Position: V 
inc = aktuellerEditor->xpos - 1; 
ptr = aktuellerEditor->puffer ♦ inc; 
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rest= aktueUerEditor’>puf len - ine; 

/* Was, wenn inc > puflen? */ 
ff (inc < HAXBREITE) 

C 

if (rest < 0) 

< 

reg 1 Ster UBYTE *p; 

p = aktueUerEditor->puffer + aktuellerEditor->puflen; 
aktuellerEditor->puflen rest; 
while (rest) 



rest++; 

> 

> 

> 

eise 

return (FALSE); 

•pptr = ptr; 

"•"pinc = inc; 

*prest= rest; 
return (TRUE); 

> 

y************************************ 

* 

* deleteChar: 

* 

* Loescht Zeichen unter dem Cursor. 

* Gibt FALSE zurueck, falls kein 

* Buchstabe mehr. 

* 

************************************^ 

BOOL deleteCharO 

UBYTE *ptr; 

UWORD inc,rest; 
register UBYTE *p1,*p2; 
regiSter UWORD l; 

if (! getPufferPointer(&ptr,&inc,&rest)) 
return (FALSE); 

\ if (rest) 

i 

p1 = ptr * 1; 
p2 = ptr; 
l = --rest; 
while (l) 
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*p2 = *p1; 

p1++; 

p2++; 

> 

*p2 = aktuellerEditor->puflastchar; 

Laenge - 1 */ 
aktuellerEditor->puflen--; 

pn* ntL 1 neCaktuellerEditor->aktuell,aktuellerEditor->yoff 
+ aktuellerEditor->ch*aktuellerEditor->wdy); 


return (TRUE); 

> 

eise 

return (FALSE); 




* backspaceChar: 

* 


* Loescht Zeichen vor Cursor. 

* Gibt FALSE zurueck, wenn 

* Cursor am Zeilenanfang. 

* 


****************************** y 


BOOL backspaceChar() 

C 

UBYTE *ptr; 

DWORD inc,rest; 
register UBYTE *p1,*p2; 
regiSter DWORD l; 

if (! getPufferPointer(&ptr,&inc,&rest)) 
return (FALSE); 

if (inc) 

if (aktuellerEditor->insert) 

C 

p1 = ptr; 
p2 = --ptr; 
l = rest; 
while (l) 

C 

♦p2 = *p1; 
p1++; 

1-; 

> 
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*p2 = aktueUerEditor->puf lastchar; 

/* Laenge - 1 */ 

aktuellerEditor->puflen--; 

inc--; 

> 

eise 

i 

*--ptr = * *; 

inc--; 

rest+-*-; 


cursorLeftO; 

printLineCaktuellerEditor->aktuell,aktuellerEditor->yoff 
* aktuellerEditor->ch*aktuellerEditor->wdy); 


return (TRUE); 

> 

eise 

return (FALSE); 


^****************************************** 


* insertChar(c) 

★ 


* Fuegt Zeichen in Puffer ein. 

* Gibt FALSE zurueck, falls Zeichen nicht 

* eingefuegt werden konnte. 

* 

* c = Zeichen. 

* 


************************************«r****«ry 


BOOL insertChar(c) 
regiSter UBYTE c; 

UBYTE *ptr; 

WORD inc,rest; 

UORD xadd - 1; 

if (! getPufferPointer(&ptr,&inc,&rest)) 
return (FALSE); 


if 

C 


((c == TAB) && (aktuellerEditor->tabs)) 

if (aktuellerEditor->insert) 
i 

/* Blanks einfuegen: V 
register UBYTE *p1,*p2; 
regiSter DWORD anz,l; 
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p1 = aktueUerEditor->tabstring + 

alctueUerEditor*>xpos - 1; 
l = MAXBREITE - aktuellerEditor->xpos; 
anz = 1; 

while (l && (*++p1)) 

< 

xadd++; 

l--; 

anz++; 

> 

!* anz = Anzahl der Blanks, die eingefuegt werden: V 
if (aktuellerEditor->puflen + anz > MAXBREITE) 
anz = MAXBREITE - aktuellerEditor->puflen; 

/* Rest der Zeile verschieben: V 
p1 = ptr rest; 
p2 = pl + anz; 
l = rest; 
while (l) 

C 

*--p2 = *--p1; 

> 

t* Blanks einfuegen: V 
p1 = ptr; 
l = anz; 
while (l) 

*p1 = • •; 
pU+; 

> 

aktuellerEditor->puf len •♦•= anz; 
rest anz; 

> 

eise 

< 

Nur Cursor bewegen: V 
regiSter UBYTE *tab; 
regiSter UWORD max; 

tab = aktuellerEditor*>tabstring 

aktuellerEditor->xpo8 - 1; 
max = MAXBREITE - aktuellerEditor*>xpo8; 
while (max && (^‘•‘'t'tab)) 

C 

xadd++; 

max--; 

> 

> 

> 
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eise 

c 

/* sonst als normales Zeichen: */ 
if (aktuellerEditor->insert) 

if (alctuellerEditor*>puflen < MAXBREITE) 

C 

regiSter UBYTE *p1,*p2; 
reg{Ster UUORD l; 

p1 = ptr + rest; 

p2 = p1; 

l = rest; 
while (l) 
i 

*p2 s *--p1; 

P2-; 

1 -; 

> 

*ptr = c; 

/* Laenge + 1 */ 
aktuellerEditor->puflen++; 
rest++; 

> 

eise 

/* Spaeter hier Word-Wrap */ 
return (FALSE); 

eise 

C 

*ptr = c; 
if (rest = 0) 

< 

aktuellerEditor->puf lerH-^; 
rest * 1; 

> 

> 

> 

/* Cursor bewegen: */ 
while (xadd) 

< 

if (I cursorRightO) break; 
xadd--; 

> 

/* Zeile ausgeben: V 

printLineCaktuellerEditor->aktuell,aktuellerEditor->yoff 
♦ aktuellerEditor->ch*aktuellerEditor->wdy); 


return (TRUE); 

> 
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/*****★★**★******★********* 

* 


* insertLine(c): 

* 

* Fuegt neue Zeile hinter 

* aktueller Zeile ein. 

* Gibt FALSE zurueck, falls 

* Fehler aufgetreten ist. 

* 


* c = Zeilenende (CR/LF). 

* 

************************** j 


BOOL insertLine(c) 

UBYTE c; 

C 

static UBYTE buf[MAXBREITE + 1]; 

UBYTE *ptr; 

register UBYTE *p1,*p2; 

WORD inc,rest,len; 

UUORD autoindent; 
register UWORD l; 
register struct Zeile *z; 

/* Nur neue Zeile einfuegen, wenn aktuelle Zeile 
keine Faltenmarkierung!M V 
if ((z = aktuellerEditor->aktuell) == NULL) 
z = ZEILENPTR(aktuellerEditor->wdy); 

if (!z II !(z->flags & ZLF_FSE)) 

{ 

/* Zeile in Puffer holen: V 
if (f getPufferPointer(&ptr,&inc,&rest)) 
return (FALSE); 

/* Auto-Indent bestimmen: V 
if (aktuellerEditor->autoindent) 

p1 = aktuellerEditor->puffer; 
l = inc; 

while (l && ((*p1 == * ') II (*p1 == TAB))) 

p1++; 

1 -; 

> 

if (l) 

autoindent = p1 - aktueUerEditor->puffer ♦ 1; 
eise 

/* Zeile besteht nur aus Spaces: V 
autoindent = 1; 

> 

eise 

autoindent = 1; 
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/* Zeile dekonvertieren: */ 
p2 = buf + (len = deconvertLine 

(buf,aktuellerEditor->puffer,inc)); 

*p2= c; 
len++; 

if (z = neueZeile(len)) 

C 

z->flags = (aktuellerEditor->aktuell->flags & ~ZLF_USED) 

/* Zeile, in der Cursor steht, abspeichern: */ 
p1 = (UBYTE *)(z + 1); 
p2 = buf; 
l = len; 

while (l) 

*p1 = *p2; 

p1++; 

p2++; 

1-; 

> 

/* Zeile einbinden: V 
Insert(&aktuellerEditor->zeilen,z, 

aktuellerEditor->aktueU->pred); 
aktuellerEditor->anz_zeilen++; 
aktuellerEditor->changed = 1; 

/* Rest der Puffer-Zeile nach vorne schieben: */ 

/* Dabei muss autoindent beachtet werden! */ 
p1 = aktuellerEditor->puffer; 
l = autoindent; 
while (--l) 

p1++; /* Alter Inhalt bleibt erhalten! */ 


p2 = ptr; 
l = rest; 
while (l) 
i 

*p^ = *p2; 

pU-»-; 

p2++; 

1 -; 

> 

aktuellerEditor->puflen = p1 - aktuellerEditor->puffer; 
/* Rest mit lastchar fuellen: */ 
l = inc + 1 - autoindent; 
while (l) 
i 

*p1 = aktuellerEditor->puflastchar; 

p1++; 

1 -; 

> 
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/* Stelle fest, ob neue Zeile Faltenmarkierung: */ 
if (l = getFoldlnc(z)) 

C 

register struct Zeile *old; 
register DWORD fold; 

z->flags 1= ZLF_FSE; 

/* Falten-Level aller folgender Zeilen ändern: */ 
if ((old = z->succ)->succ) 
while (old->succ) 

< 

old->flags = (old->flags & "ZLF FOLD) 

I ((old->flags + l) & ZLF^FOLD); 
old = old‘>succ; 

> 


/* ggf. minfold und maxfold anpassen: V 
if (d >0) |j ((z->flags & ZLF^FOLD) > 0)) 


fold = (z->flags & ZLF_.FOLD) + l; 
if (aktuellerEditor->minfold > fold) 
aktuellerEditor->minfold = fold; 
if (aktuellerEditor->maxfold < fold) 
aktuellerEditor->maxfold = fold; 


> 


> 


ZEILENPTR(aktuellerEditor->wdy) = z; 
aktuellerEditor->wdy = 

recalcTopOfWindow(aktuellerEditor->wdy); 


/* Falls Cursor auf oberster Zeile 
=> zeilenptrCO] aendern: */ 
if (aktuellerEditor->wdy == 0) 

ZEILENPTR(O) = z; 

restoreZeilenptr(); 

/♦ Fenster neu ausgeben: */ 
aktuellerEditor->xpos = autoindent; 
if (aktuellerEditor->xpos <= aktuellerEditor->leftpos) 
< 


/* Falls waagerechtes Scrolling noetig: printAll */ 
aktuellerEditor->leftpos = aktuellerEditor->xpos - 1; 
if (++aktuellerEditor->wdy >= aktuellerEditor->wch) 

C 


ZEILENPTR(O) = ZEILENPTR(1); 
ZEILENNR(O) = ZEILENNR(1); 
restoreZei lenptrO; 
aktuel lerEdi tor->wcly--; 
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aktuellerEditor->ypos = 

ZEILENNR(aktueUerEditor->wcly); 

pn’ntAllO; 

> 

eise 
if (l) 
i 

/* falls Faltenmarkierung: 

Ganzes Fenster neu ausgeben :V 
if (++aktuellerEditor->wdy >= aktuellerEditor->wch) 
i 

ZEILENPTR(O) = ZEILENPTR(1); 

ZEILENNR(O) > ZE1LENNR(1); 
restoreZei lenptrO; 
aktuel lerEdi tor->wcly- -; 

> 

aktuellerEditor->ypos = 

ZEILENNRCaktuellerEditor’>udy); 

printAll(); 

> 

eise 

C 

/* Es wird gescrollt: V 

if <++aktuellerEditor->wdy >= aktuellerEditor->wch) 
i 

/* Cursor war auf letzter Zeile: V 
regiSter DWORD nr; 

scrollUp((DWORD) 1); 

nr = (--aktuellerEditor->wdy) - 1; 

aktuellerEditor->ypos= 

ZE1LENNR(aktuellerEditor->wdy); 
printLine(ZEILENPTR(nr),aktuellerEditor->yoff 

aktuel lerEdi tor->ch*nr); 

> 

eise 

i 

/* Cursor steht irgendwo mitten im Fenster: */ 
regiSter DWORD nr; 

if (ZEILENPTR((nr = aktuellerEditor->wdy) + 1)) 

< 

/* Rest des Fensters nach unten schieben: 
ScrollRaster(aktuellerEditor->rp, 

OL,(LONG)-aktuellerEditor->ch, 
(LONG)aktuellerEditor->xoff, 
(LONG)aktuellerEditor->yoff 
aktuel lerEdi tor->wdy 
*aktuellerEditor->ch, 
(LONG)aktuellerEditor->xscr, 
(LONG)aktuellerEditor->yscr); 

> 
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aktueUerEditor*>ypos=ZEILENNR 

(aktuellerEditor->wdy); 


printLine(ZEILENPTR(nr),aktuellerEditor->yoff 

••• aktueUerEditor->ch*nr); 


> 


> 


nr--; 

pn*ntLi ne(ZEILENPTR(nr),aktuel lerEdi tor->yof f 

+ aktuellerEditor->ch*nr); 


return (TRUE); 

> 

eise 

return (FALSE); 

> 

eise 

C 

cursorHomeO; 
cursorDoun(); 

return (FALSE); 

> 

> 


/**************************** 

* 

* deleteLine: 

* 


* Loescht die Zeile, 

* auf der der Cursor steht. 

* Gibt FALSE zurueck; falls 

* die Zeile nicht geloescht 

* werden konnte. 


**************************** y 


BCX)L deleteLineO 
C 

register struct Zeile *zeile,*next,^prev; 
regiSter DWORD 1=0; 

DWORD nextnr,prevnr; 

if (Zeile = ZEILENPTR(aktuellerEditor->wdy)) 
i 

/* Verweise auf Zeile loeschen: V 
if (Zeile == aktuellerEditor->aktuell) 

< 

aktuellerEditor->aktuell = NDLL; 
aktuellerEditor->pufypos * 0; 
aktuellerEditor*>puflen = 0; 

> 
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aktuellerEditor->changed =1; 
aktueUerEditor->an 2 _ 2 ei len--; 

i* Folding ggf. rekonstruieren: V 
if ( 2 eile->flags & ZLF FSE) 

C 

register struct Zeile * 2 ; 

/♦ Falten-Level aller folgender Zeilen ändern: */ 
if ((2 = 2 eile->succ)->succ) 

C 

if (((2eile->flags+1) & ZLF FOLD) == 

( 2 ->flags & ZLF_FOLD)) 

/♦ Zeile war Faltenanfang: V 
l = -1; 

else if (( 2 eile->flags&ZLF FOLD)=:= 

(( 2 ->flags+1)&ZL F^FOLD)) 

/* Zeile war Faltenende: V 
l = 1; 
else 
l = 0; 

if (l) 

while ( 2 ->succ) 

< 

2 ->flags = ( 2 ->flags & "ZLF FOLD) 

I (< 2 ->flags + l) & ZLF^FOLD); 

2 = 2 ->succ; 

> 

> 

> 

/* Naechste und vorige Zeile merken: V 
prevnr= ZEILENNR(aktuellerEditor->wdy); 
prev = prevLine( 2 eile,&prevnr); 
nextnrs ZEILENNR(aktuellerEditor->wdy); 
next = nextLine( 2 eile,&nextnr); 

/* Sicherheitsabfrage: V 

while ((prev==NULL) && (next^^^NULL) && 

(aktuellerEditor->minfold)) 

< 

1=1; /* Fenster komplett neu ausgeben V 

aktuellerEditor->minfold--; 

prevnr= ZEILENNR<aktuellerEditor->wdy); 
prev = prevLine( 2 eile,&prevnr); 
nextnr= ZEILENNRCaktuellerEditor->wdy); 
next = nextLine( 2 eile,&nextnr); 

if (prev jj next) break; 

if (aktuellerEditor->minfold) continue; 

if ((next = aktuellerEditor-> 2 eilen.head)->succ == NULL) 
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next = NULL; 
eise 

nextnr = 1; 
break; 

> 

/* Zeile loeschen: V 
loescheZeileCzeile); 

/* Zeiger auf aktueller Zeile neu setzen fuer recalc: V 
if (next) 

C 

ZEILENPTR(aktuellerEditor->wdy) = next; 
ZEILENNR(aktuellerEditor->udy) = nextnr; 

> 

eise 

i 

ZEILENPTR(aktuellerEditor->wdy) = prev; 

ZEILENNRCaktuellerEditor*>wdy) = prevnr; 

> 

/* Nun Fensterinhalt restaurieren: V 
if <l) 
i 

/* Fenster auf jeden Fall ganz neu ausgeben: V 
aktuellerEditor->wdy = 

recalcTopOfWindow(aktuellerEditor->wdy); 
restoreZei lenptrO; 
printAll(); 
cursorOnTextO; 

> 

eise 

i 

/* Mit Scrolling: V 
register UWORD oldudy; 

oldwdy = aktuellerEditor*>wdy; 
aktuellerEditor'>wdy » 

recalcTopOfUindow(aktue11erEditor* >wdy); 
restoreZei lenptrO; 

if (next) 

C 

/* Unteren Rest des Fensters nach oben schieben: V 
ScrollRaster(aktuellerEditor->rp, 

OL,(LONG)aktuellerEditor->ch, 
(LONG)aktueUerEditor->xoff, 
(LONG)aktueUerEditor->yoff + 
aktuellerEditor->wd/*aktuellerEditor*>ch, 
(LONG)aktuellerEditor->xscr, 

(L()NG)aktuel lerEdi tor->yscr ); 


printLine(ZEILENPTR(aktuellerEditor->wch - 1) 
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aktueUerEditor->yoff + 

aktueUerEditor->ch*(aktueUerEditor->wch - 1)); 

> 

eise 

if (oldwdy == aktueUerEditor’>wdy) 

C 

/* Oberen Teil des Fensters nach unten scrollen: V 
ScrollRaster(aktuellerEditor~>rp, 

OL,(LONG)-aktuellerEditor->ch, 

< LONG)aktue11erEditor->xof f, 
(LONG)aktuellerEditor’>yoff, 
(LONG)aktuellerEditor‘>xscr, 
(LONG)aktuellerEditor*>yoff 

* (aktuellerEditor->wdy + 1) 
♦aktuellerEditor->ch - 1); 

printLine(ZEILENPTR(0),aktuellerEditor->yoff); 

> 

eise 

printLine(ZEILENPTR(oldwdy),aktuellerEditor’>yoff 
aktuel lerEdi tor->ch♦oldwdy); 


cursorOnText<); 

> 

return (TRUE); 

> 

eise 

return (FALSE); 


Hier nun ein paar Bemerkungen zu den Funktionen: 

Am Anfang des Moduls sind als globale Variablen die 
Zeichenketten definiert, die eine Faltenmarkierung dar¬ 
stellen. Dabei gibt FSE_SIG die Anzahl der signifikanten 
Zeichen für die Faltenmarkierung an; in unserem Fall wäre 
also /*#FOLD: signifikant für den Faltenanfang (fold- 
Anfang) und /*#ENDFD für das Faltenende (foldEnde). 
Diese Zeichenketten lassen sich beliebig ändern, so daß 
sich der Editor auch an andere Programmiersprachen an¬ 
passen läßt, also z.B. ;#FOLD: in Assembler. Das Define 
FSE_LEN gibt die gesamte Länge der Zeichenketten an, 
wobei, wie auch bei der Anzahl der signifikanten Stellen, 
diese für Faltenanfangs- und Faltenendemarkierung gleich 
sein muß (der Einfachheit halber). Die gesamte Länge 
werden wir später noch gebrauchen können, wenn wir das 
Wegfalten von Textstücken automatisieren. Dann muß der 
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Editor eine Zeile vor und eine nach dem Faltentext einfü- 
gen, die dann die Faltenmarkierungen darstellen. Damit Sie 
nicht das Kommentarende vergessen, wird dieses gleich 
mit eingefügt. 

In der Funktion getLineForEdit können Sie bereits die 
Änderung der Funktion convertLineForPrint erkennen. Sie 
gibt nun die Länge der konvertierten Zeile zurück. Als 
fünften Parameter müssen Sie nun einen Zeiger auf eine 
UBYTE-Variable übergeben, in der dann lastchar abge¬ 
speichert wird. 

Neu ist die Funktion cursorOnText, die überprüft, ob sich 
der Cursor noch auf einer existierenden Zeile befindet, 
oder ob er bereits hinter das Textende (Faltenende) bewegt 
wurde. Im zweiten Fall wird der Cursor auf die unterste 
im Fenster sichtbare Zeile gesetzt. 

Die Funktion deconvertLine stellt das Gegenstück zur 
Funktion convertLineForPrint aus dem Modul Ausgabe 
dar. Das Erzeugen von Tabulatoren geschieht dabei folgen¬ 
dermaßen: An jedem Tabulator (tab » O) überprüft die 
Funktion, ob sich vor diesem Blanks befinden (fb != 0). Ist 
dies der Fall, so werden alle Blanks durch ein Tabulator 
(TAB) ersetzt. 

Eine weitere Option des Editors finden Sie ebenfalls in der 
Funktion convertLineForPrint. Wenn das Flag aktueller- 
Editor->skipblanks gesetzt ist, so werden alle Blanks, die 
am Ende einer Zeile stehen, gelöscht, da sie meist über¬ 
flüssig sind. Wenn wir jedoch Fließtext mit unserem Editor 
eingeben wollen, so dürfen diese nicht gelöscht werden, 
weswegen dieses Feature abschaltbar ist. 

Die Funktion getFoldlnc bestimmt, ob eine Zeile eine 
Faltenmarkierung darstellt, und gibt Null zurück, falls dies 
nicht der Fall ist. Andernfalls erhalten wir eine 1, wenn es 
sich bei der Zeile um eine Faltenanfangsmarkierung han¬ 
delt, und -1 für das Faltenende. Diese Werte wurden mit 
Rücksicht auf die Funktion saveLine gewählt, auf die wir 
jetzt zu sprechen kommen. 
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Die Funktion saveLine hat einiges zu tun, um die Falten- 
Level richtig einzustellen, wenn die Zeile eine Fal¬ 
tenmarkierung war. 

Dazu folgende Überlegungen: War die Zeile vor der Änderung 
keine Faltenmarkierung und ist sie danach ein Faltenanfang, 
dann muß der Falten-Level aller folgenden Zeilen um eins er¬ 
höht werden. 

War die Zeile vor der Änderung ein Faltenanfang und ist sie da¬ 
nach keine Faltenmarkierung mehr, so muß der Falten-Level 
aller folgenden Zeilen um eins vermindert werden. 

Dieses gilt analog für das Faltenende, wobei nur Erhöhung und 
Verminderung vertauscht werden müssen. Wenn die Zeile jedoch 
sowohl vor als auch nach der Änderung eine Faltenmarkierung 
war, so wird die Sache kompliziert. Aber nur so lange, bis wir 
eine Wertetabelle aufstellen, aus der hervorgeht, um welchen 
Wert der Falten-Level aller folgenden Zeilen erhöht werden 
muß, in Abhängigkeit davon, ob die Zeile vor oder nach der 
Änderung eine Faltenmarkierung war oder nicht. Stellen Sie 
diese Tabelle doch einmal selbst auf, und Sie werden feststellen, 
daß folgende Vorgehens weise zum korrekten Ergebnis führt: 
Man bestimme mit der Funktion getFoldlnc, ob es sich bei der 
geänderten Zeile um eine Faltenmarkierung handelt, und merke 
sich den Rückgabewert. Elann tue man dasselbe mit der Zeile 
vor der Änderung, wobei wir dafür nicht die Funktion getFold¬ 
lnc benutzen, sondern den Falten-Level der Zeile mit dem der 
nächsten Zeile vergleichen. In diesem Fall nehmen wir jedoch 
den negativen Wert bezüglich getFoldlnc, also -1 für Anfang 
und +1 für Ende. Nun addieren Sie beide Werte, und Sie erhal¬ 
ten den Wert, um den die Falten-Level aller folgenden Zeilen 
erhöht werden müssen. 

Soviel zum Thema Folding. Ein Flag, das wir schon früher ein¬ 
geführt haben, damit wir feststellen können, ob wir bereits et¬ 
was an unserem Text geändert haben, ist das changed-Flag aus 
der Editor-Struktur. Wenn wir mit saveLine eine Zeile endgültig 
geändert haben (vorher können wir dies ja noch durch Undo 
rückgängig machen), müssen wir dieses Flag setzen, damit es 
seinen Zweck erfüllen kann. 
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Ganz am Ende der Funktion wird die Zeile dann nochmals aus¬ 
gegeben, da es ja sein kann, daß Blanks am Ende abgeschnitten 
worden sind, was vor allem bei Zeilen ohne Zeilenende zu einer 
Änderung der Darstellung auf dem Bildschirm führen würde. 

Bei der Funktion getPufferPointer handelt es sich um eine 
Hilfsfunktion, die eine Zeile in den Editorpuffer kopiert, 
oder besser, konvertiert. Dabei initialisiert sie drei Vari¬ 
ablen, die das Editieren vereinfachen, und zwar einen Zei¬ 
ger auf das Zeichen, auf dem sich der Cursor befindet, die 
Anzahl der Zeichen links vor dem Cursor und die Länge 
des Restes der Zeile. Befindet sich der Cursor jedoch hin¬ 
ter dem letzten Zeichen der Zeile, so werden so viele 
Leerzeichen eingefügt, daß zumindest direkt links vom 
Cursor ein Zeichen steht. Unter dem Cursor selbst braucht 
keines zu sein, da dort z.B. von der Funktion insertChar 
ein Zeichen eingefügt werden würde. 

Zur Funktion insertChar wäre noch zu sagen, daß Tabula¬ 
toren im Überschreibmodus nur den Cursor nach rechts 
bewegen, nicht aber den Text ändern, also auch keine 
Blanks über den Text schreiben. 

Die Funktion insertLine erlaubt es nicht, eine Faltenmar¬ 
kierung durch Drücken von Return aufzuteilen. Dies liegt 
daran, daß man aus einer alten Zeile zwei neue (geänderte) 
erhält. Und dann die Falten-Level anzupassen... Deswegen 
haben wir uns erlaubt, diesen Sonderfall auszuschließen, 
was aber nicht heißen soll, daß Sie sich nicht an die Arbeit 
machen sollten, um diese Lücke zu füllen. Aber das bleibt 
Ihnen überlassen. Sehr wohl ist es erlaubt, eine Faltenmar¬ 
kierung neu einzugeben und diese Zeile mit Return zu 
beenden, aber in diesem Fall ist das Ändern der Falten- 
Level der folgenden Zeilen auch harmlos. 

Eine andere Sache ist die Ausgabe des Textes im Fenster. Da¬ 
durch, daß wir eine neue Zeile eingefügt haben, stimmt der 
Fensterinhalt ja nun nicht mehr. Wir könnten die Funktion 
printAll benutzen, aber das wäre viel zu langsam. Also müssen 
wir Scrollen! In der insertLine sind wir dabei folgendermaßen 
vorgegangen: 
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Wenn der Fensterinhalt ohnehin horizontal gescrollt werden muß 
oder wenn die neu eingefügte Zeile eine Faltenmarkierung ist, 
so geben wir den Fensterinhalt doch mit printAll neu aus. Dies 
wäre zwar beim horizontalen Scrollen nicht nötig, aber wenn wir 
erst den Fensterinhalt horizontal und dann nochmal vertikal 
Scrollen, so ist printAll auch nicht sehr viel langsamer. Andern¬ 
falls wird vertikal gescrollt, und zwar der Teil des Textes ab der 
Cursor-Position nach unten. Befand sich der Cursor aber schon 
in der untersten Zeile, so wird der gesamte Fensterinhalt nach 
oben gescrollt. 

Auch in der Funktion deleteLine muß gescrollt werden, 
hier bleibt der Cursor aber auf der aktuellen Zeile stehen, 
und der Rest des Textes wird nach oben gescrollt. Erst 
wenn der Cursor auf der letzen Zeile stand, wird der obere 
Teil des Textes nach unten gescrollt. Befindet sich auch 
kein Text mehr oberhalb des Fensters, so wird die Y-Posi- 
tion des Cursors vermindert. 

Ein weiteres Problem in dieser Funktion tritt auf, wenn der 
Cursor in einer Falte am Textende steht (minfold > 0) und dort 
alle Zeilen gelöscht werden. Dann kommt der Editor nämlich 
nicht mehr an die Zeilen über dieser Falte heran, weswegen die 
Funktion deleteLine in einem solchen Fall so lange minfold 
vermindert, bis sie eine Zeile findet. 

Die Faltenmarkierung können Sie auch mit deleteLine löschen. 
Dann werden die Falten-Level aller folgenden Zeilen entspre¬ 
chend umgerechnet. 

So weit, so gut. Die Änderungen an den anderen Modulen sind 
diesmal relativ umfangreich ausgefallen, weswegen wir gleich 
mit Editor.h beginnen wollen. Hier haben wir aus der Editor- 
Struktur die Variable toppos gestrichen, da unser Feld zeilennr 
dessen Funktion bereits erfüllt hat. Neu hinzugekommen sind 
dagegen folgende Elemente: 

UBYTE puflastchar; 

UUORO puflen,pufypos; 

UWORD tabs : 1; 

DWORD skipblanks : 1; 

DWORD autoindent : 1; 
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Als nächstes kommt das Modul Ausgabe.c an die Reihe, in dem 
wir unter anderem die Funktion convertLineForPrint anpassen 
müssen. Hier zunächst der geänderte Funktionskopf: 

DWORD convertLineForPrint( 2 eile,len,u,buf,Ic) 

UBYTE *zeile; 

regiSter WORD len; 

regiSter DWORD w; 

regiSter DBYTE *buf; 

DBYTE *lc; 

Ferner benötigen wir noch eine weitere lokale Variable: 

DWORD realLen; 

In dieser Variablen halten wir die tatsächliche Länge der kon¬ 
vertierten Zeile fest. Die folgende Konvertierung bleibt so be¬ 
stehen, wie sie war. Aber bevor der Rest der Zeile mit lastchar 
gefüllt wird, müssen wir uns die Länge der Zeile merken: 

/* Tatsaechliche Laenge der Zeile retten: V 
realLen =1-1; 

Nun wird der Rest der Zeile mit lastchar gefüllt, und danach 
geben wir die tatsächliche Länge zurück: 

♦Ic = lastchar; 
return (realLen); 

Die Änderungen in der Funktion printLine, die wir nun vor¬ 
nehmen müssen, sind so groß, daß wir diese Funktion komplett 
auflisten. Diese Funktion gibt nun den Puffer aus, wenn das 
ZLF_USED-Flag der Zeile gesetzt war. Existierte die Zeile gar 
nicht (zeile * Null), so wird der entsprechende Fensterbereich 
gelöscht, was wir uns bereits bei der Funktion deleteLine zu¬ 
nutze gemacht haben: 

void printLine (zeile,y) 

register struct Zeile *zeile; 
regiSter DWORD y; 

i 

static DBYTE buf[HAXBREITE]; 

if (Zeile) 

C 


register struct Zeile ^z; 
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register UBYTE *p1,*p2; 
regiSter DWORD w; 
register ULONG pen; 

UBYTE Ic; 

/* Pruefe, ob Zeile gerade bearbeitet wird: */ 
if (zeile->flags & ZLF USED) 
i 

/* Puffer nach buf kopieren, da printAt diesen veraendert! V 
if (MAXBREITE > aktuellerEditor->leftpos) 
i 

w - HAXBREITE • aktuellerEditor->leftpos; 
p2 = aktueUerEditor->puffer + 

aktuel lerEdi tor->lef tpos; 

pl = buf; 
while (w) 
i 

’^'p! = *p2; 

p1++; 

p2+-»*; 

w--; 

> 

> 

eise 

pl = buf; 

/* Nun Rest mit lastchar fuellen: V 
p2 * buf (w = aktuel lerEdi tor->wcw); 

Ic = aktuellerEditor*>puflastchar; 
while (pl < p2) 
i 

*p1 = Ic; 
pU*; 

> 

> 

eise 

convertLineForPrint(zeile+1,zeile->len, 

w = aktuellerEditor->wcw,buf,&lc); 

/* Falls Anfang/Ende-Markierung einer Falte => FOLDPEN V 
if (zeile->flags & ZLF FSE) 
i 

if ((z = zeile->succ)->succ) 
i 

if ((Z’>flags & ZLF FOLD) <= aktuellerEditor->maxfold) 
C 

SetAPen(aktuellerEditor-> rp,FOLDPEN); 
pen » FOLDPEN; 

> 

eise 

pen s FGPEN; 

> 

eise 
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i 

SetAPen(aktue11erEditor->rp, FOLDPEN); 
pen = FOLDPEN; 

> 

printAt(buf,w - spaltenDec,aktuellerEditor->xoff,y,pen); 

/* Alte Schreibfarbe wieder einstellen: */ 
if (pen != FGPEN) 

SetAPen(aktuellerEditor->rp,FGPEN); 

> 

eise 

printAt(buf,w - spaltenDec, 

aktuellerEditor->xoff,y,FGPEN); 

> 

eise 

< 

/* Falls keine zeile => Im Fenster loeschen: */ 
struct RastPort *rp = aktuellerEditor->rp; 

SetAPen(rp,BGPEN); 

RectFill(rp,(ULONG)aktuellerEditor*>xoff, 

(ULONG)y, 

(ULONG)aktuellerEditor>>xscr, 

(ULONG)y aktuellerEditor->ch - 1); 

SetAPenCrp,FGPEN); 

> 

> 

Auch das Modul Cursor mußte sich einige Änderungen gefallen 
lassen. Neu ist die Funktion recalcTopOfWindow, die von einer 
beliebigen Zeilenposition ausgehend clie oberste Zeile des Fen¬ 
sters bestimmt und in den Feldern zeilenptr und zeilennr ab¬ 
speichert. Zweck dieser Funktion ist es, nach einer Änderung 
des Textes oder von minfold und maxfold das zeilenptr-Feld so 
zu initialisieren, daß der Cursor möglichst auf seiner alten Posi¬ 
tion stehen bleibt. 

UUORD recalcTopOfUindow(y) 
regiSter UUORD y; 

C 

register struct Zeile *z,*zp; 
register UUORD znrp; 

UUORD znr,oldy = y; 

z s ZEILENPTR(y); 
znr = ZEILENNR(y); 
while (y) 
i 


zp = z; 
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znrp = znr; 

if ((z = prevLine(z,&znr)) == NULL) 
break; 

y--; 

> 

if (y) 
i 

ZEILENPTR(O) - zp; 

ZEILENNR(O) - znrp; 

> 

eise 

ZEILENPTR(O) - z; 

ZEILENNR(O) = znr; 

> 

return <olcly - y); 

> 

Diese Funktion wird vor allem beim Austreten aus einer Falte 
und beim Löschen von Zeilen verwendet, damit der Cursor in 
der aktuellen Zeile stehenbleibt und der Benutzer ihn nicht erst 
großartig suchen muß. Zurückgegeben wird von dieser Funktion 
die neue Zeilenposition, die normalerweise mit der alten Zeilen¬ 
position übereinstimmt. Nun kann es aber vor allem nach dem 
Austreten aus einer Falte Vorkommen, daß der Cursor relativ 
weit unten im Fenster stand, aber nicht soviel Text sichtbar ist. 
Dann muß der Cursor entsprechend nach oben verschoben wer¬ 
den, wofür die neue Position direkt von dieser Funktion über¬ 
nommen werden kann. 

Die Programmstücke zum Behandeln von Falten haben wir aus 
der Funktion handleKeys ausgelagert und in eigene Funktionen 
gepackt, um sie übersichtlicher zu machen: 

y*************************** 

* 

* enterFold: 

* 

* Tritt in eine Falte ein. 

* 

*************************** ^ 

void enterFoldO 
< 


register struct Zeile *z; 
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if (aktueUerEditor->inaxfold < ZLF^FOLD) 
i 

aktuel lerEdi tor->iiiaxf old++; 
if (z =: ZEILENPTR(aktueUerEditor->wdy)) 
if (<2 = z->succ)->succ) 

/* Wenn es eine nachfolgende Zeile gibt: */ 
if (((ZEILENPTR(aktuellerEditor->wdy)-> 

flags & ZLF FOLD) 

< (z->flags & ZLF FOLD)) 

&& ((z->flags & ZLF^FOLD) == 

aktuellerEditor*>maxfold)) 
i 

/* Und wenn diese Anfang einer neuen Falte ist: V 
aktuellerEditor’>minfold * 

aktuellerEditor->maxfold; 

ZEILENPTR(O) = z; 

ZEILENNR(O) - ZEILENNR(aktuellerEditor->udy) 1; 
aktuellerEditor->udy * 0; 

> 

aktuellerEditor->udy - recalcTopOfWindow 

(aktuellerEditor->wdy); 

restoreZei lenptrO; 
printAlU); 

aktuellerEditor->ypos = ZEILENNR(aktuellerEditor*>wdy); 

> 

> 

* 

* exitFold: 

* 

* Tritt aus einer Falte aus. 

* 

*****************************! 

void exitFoldO 

regiSter UWORD wdy; 
if (aktuellerEditor*>fiiaxfold) 
aktuellerEditor->maxfoId--; 

if (aktuellerEditor->ininfold > aktuellerEditor->maxfold) 
aktuellerEditor->minfold « aktuellerEditor->maxfold; 

wdy s aktuellerEditor->wdy; 
if (ZEILENPTR(^) » NULL) 

aktuellerEditor->wdy » wdy > 0; 

if (ZEILENPTR(wdy)) 

if (((ZEILENPTR(wdy)->flag8 & ZLF_FOLD) 

> aktuel lerEdi tor->iiiaxfold) 
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II ((ZEILENPTR(Mdy)->flags & ZLF_FOLD) 

< aktuellerEditor->ininfold)) 

ZEILENPTR(wdy) - 

prevLine(ZE1LENPTR(wdy),&(ZEILENNR(udy))); 

aktueUerEditor*>wdy = recalcTopOfWindow(udy); 

restoreZei lenptrO; 

printAlU); 

cursorOnTextO; 

> 

> 

In der letzten Funktion sehen Sie auch, wie die Funktion recalc- 
TopOfWindow eingesetzt wird. Zusätzlich zu den bisherigen 
Funktionen zur Cursor-Bewegung brauchen wir noch eine, die 
den Cursor auf den Anfang der Zeile setzt, da wir diese in der 
Funktion insertLine bereits verwendet haben: 


BOOL cursorHonieC) 

{ 

aktuellerEditor->xpos =1; 
if (aktuel lerEclitor->leftpos) 

scrollRight(aktuellerEditor->leftpos); 

return (TRUE); 

> 

Bevor wir nun handleKeys, das ebenfalls geändert wurde, aufli- 
sten, müssen wir noch einige Defines definieren, auf die wir in 
der Funktion zurückgreifen: 

«kleflne CHOME 'A* 

#define UNDO •?■ 

#define CFOLD 6 
«define CENDF 5 
#define TABMODE 20 
«define URITEMOOE 15 
#define AUTOINOENT 1 
#define DELLINE 2 
#define DEL 127 
#define BS 8 
#define LF 10 
#define CR 13 


Doch nun zur Funktion handleKeys, die wir komplett auflisten, 
da sich dort einiges getan hat: 
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void handleKeys(buf,len) 
register UBYTE *buf; 
regiSter WORD len; 

< 

register UBYTE first; 

while (len > 0) 
i 

first = *buf; 

buf++; 

len--; 

if ((first == CSI) && (len > 0)) 
i 

len--; 

switch (*buf++) 
i 

case CDU: 

cursorUpO; 
break; 
case CUD: 

cursorDown(); 
break; 
case CUF: 

cursorRightO; 
break; 
case CUB: 

cursorLeftO; 
break; 
case SU: 

halfPageOownO; 
break; 
case SD: 

halfPageUpO; 
break; 
case * •: 

if (len > 0) 

C 

len--; 

switch (*buf++) 
i 

case CHOME: 
cursorHomeO; 
break; 
default: 

if (! insertChar((UBYTE)CSI)) 
Display6eep(NULL); 
buf -= 2; 
len ♦= 2; 

> 

break; 

> 

eise 

goto noCSI; 
case UNDO: 
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if (den > 0) && (*buf == '*’*)) 

< 

buf++; 

len--; 

undoLineO; 

break; 

> 

/* Sonst: default */ 
default: 

noCSI: 

t* Keine Komnando-Sequenz! V 
if (! insertChar((UBYTE)CSI)) 

DisplayBeepCNULL); 

buf--; 

len++; 

break; 

> /* switch (first) V 

> 

eise 

switch (first) 

case CFOLD: 
enterFoldO; 
break; 
case CENDF: 
exitFoldO; 
break; 

case TABMOOE: 

aktuellerEditor->tabs - faktuellerEditor->tabs; 

printAllO; 

break; 

case WRITEMODE: 

aktuellerEditor->insert = laktuellerEditor->insert 
break; 

case AUTOINDENT: 

aktuellerEditor->autoindent= 

!aktuellerEditor->autoindent; 

break; 

case DELLINE: 

if (! deleteLineO) 

DisplayBeep(NULL); 
break; 
case DEL: 

if (! deleteCharO) 

DisplayBeep(NULL); 
break; 
case BS: 

if (I backspaceCharO) 

DisplayBeep(NULL); 
break; 
case LF: 
case CR: 

if (! insertLine(first)) 
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Display8eep(NULL); 

break; 

defautt: 

if (! insertChar(first)) 

DisplayBeep(NULL); 

> /* switch (first) */ 

> /* while (len) */ 

> 

In der ersten Switch-Case-Anweisung werden wie bisher die 
CSI-Sequenzen behandelt. Ungünstig ist, daß diese CSI-Sequen- 
zen nicht eine feste Länge haben, sondern daß einige zwei, an¬ 
dere drei Zeichen lang sind. In dieser Anweisung liegt eine 
weitere Switch-Case-Anweisung, die alle Sequenzen, die mit CSI 
’ ’ beginnen, bearbeitet. Dies ist im Moment nur CSI ’ ’ ’A’, was 
über Shift-Cursor-Iinks abgeschickt wird. Wir können dies aber 
später noch erweitern, auch um selbst definierte Sequenzen. 

Die zweite große Switch-Case-Anweisung behandelt die Con¬ 
trol-Zeichen, die im Moment noch einige Funktionen auf rufen. 
Später werden wir einen Teil davon über die Kommandozeile 
aufrufen. Doch nun zunächst ein Überblick über die Tastenbele¬ 
gung des Editors, damit Sie diesen dann gleich auch ausprobie¬ 
ren können; 


Tasten 


Kommentar 


Cursor-Tasten 

Shift - Cursor-hoch/runter 

Shift - Cursor- links 

Help 

Ctrl-A 

Ctrl-B 

Ctrl-E 

Ctrl-F 

Ctrl-0 

Ctrl-T 

Delete 

Backspace 


Bewegen Cursor um ein Zeichen/Zeile. 

Scrolle Text um halbe Seite nach oben bzw. 
nach unten. 

Setze Cursor auf Zeilenanfang. 

Undo. 

Schalte Auto-Indent an/ab. 

Lösche Zeile, auf der der Cursor steht. 

Trete aus einer Falte aus. 

Trete in eine Falte ein. 

Schalte zwischen Einfüge- und Überschreib¬ 
modus um. 

Schalte Tabulatoren ein/aus. 

Wie gewohnt. 

Wie gewohnt. 


Die Funktionen, die aus dem neuen Modul Edit stammen, müs¬ 
sen Sie noch deklarieren, was wir jetzt fast vergessen hätten: 
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void undoLineO; 
void cursorOnTextO; 

BOOL insertCharC),deleteChar(),backspaceChar(), 

1nsertLine(),deleteLine(); 

Im Modul Speicher haben wir die Funktion loescheZeile dahin¬ 
gehend geändert, daß nun der Inhalt des zeilenptr- und zei- 
lennr-Feldes nicht mehr geändert wird und daß die Zeile nicht 
aus der Liste aller Zeilen gelöscht wird; wir haben also folgende 
Befehle ersatzlos gestrichen: 

/* Zeile aus Liste entfernen: */ 

RemoveCzeile); 

/* eventuelle Zeiger auf diese Zeile auf Null setzen: V 
if (aktuellerEditor‘>alctuell == zeile) 
aktuellerEditor->aktuell = NULL; 
for (n s 0, zptr = aktuellerEditor->zeilenptr; 
n <= aktuellerEditor’>uch; n++, zptr-*--»-) 
if (*zptr == zeile) 
i 

♦zptr = NULL; 
break; 

> 

Dies war nötig, damit die Funktion deleteLine einwandfrei 
funktionieren kann. Nun noch ein paar Änderungen im Haupt¬ 
modul. In der Funktion OpenEditor müssen die zusätzlichen 
Elemente der Editor-Struktur auch initialisiert werden: 

ed->puflen = 0; 
ed->pufypos = 0; 
ed->puflastchar* * *; 
ed->tabs = 1; 

ed->skipblanks =1; 
ed->autoindent = 1; 

Ferner dürfte Ihnen schon beim Testen des Cursors aufgefallen 
sein, daß der Cursor vor allem beim horizontalen Scrollen nach¬ 
läuft, das heißt, daß Sie die Taste längst losgelassen haben, der 
Cursor läuft aber immer noch weiter. Dieser Effekt tritt bei al¬ 
len anderen Funktionen, die den Cursor bewegen oder Text 
einfügen, auch auf, aber erst, wenn Sie den Tastatur-Repeat auf 
sehr schnell stellen, also in Preferences den Schieber dafür ganz 
nach rechts schieben. 
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Dieser Effekt läßt sich nun relativ einfach unterbinden, indem 
wir, nachdem wir einen Tastendruck bearbeitet haben, überprü¬ 
fen, ob schon wieder neue ins Haus stehen. Ist dies der Fall und 
haben alle RAWKEY-Messages das REPEAT-Flag gesetzt, so 
wird die erste Message entfernt. Das REPEAT-Flag wird vom 
Betriebssystem gesetzt, wenn eine RAWKEY-Message wegen des 
Tastatur-Repeats auftritt, weil der Benutzer die Taste gedrückt 
gehalten hat. Messages, bei denen das REPEAT-Flag nicht ge¬ 
setzt ist, werden nicht gelöscht, da es unter Umständen sein 
könnte, daß der Benutzer Tasten schneller drückt, als unser 
Editor diese bearbeiten kann. In diesem Fall darf der Editor 
nicht einfach welche verschlucken. 


Nun wird so lange die aktuelle Message gelöscht, bis nur noch 
eine übrig ist. Diese wird dann beim nächsten Durchlauf durch 
die Hauptschleife bearbeitet. Prinzipiell könnten wir auch die 
erste Message löschen, aber die Cursor-Bewegung wäre dann et¬ 
was ruckelig oder oszillierend, wie Sie es z.B. bei manchen Text¬ 
verarbeitungen beobachten können. Den Vorteil unserer gleich¬ 
mäßigen Cursor-Bewegung erkaufen wir uns allerdings mit dem 
kleinen Nachteil, daß unser Cursor schlimmstenfalls ein Zeichen 
weiter läuft als geplant. 


Die RAWKEY-Abfrage sieht nun wie folgt aus: 


case RAWKEY: 

register struct IntuiMessage * 11111 ,*iin2; 

if (! (Code & lECOOE UP PREFIX)) 

inputEvent.ie_Cocle = Code; 
inputEvent.ie_Qualifier » qualifier; 
if ((inputLen « RawKeyConvert( 

&{nputEvent,inputPuffer,MAXINPUTLEN,NULL) 

) >= 0 ) 

handleKeys(inputPuffer,inputLen); 

> 


/* Nachlaufen verhindern: */ 

iml s (struct IntuiMessage *}edUserPort->inp_MsgList.lh_Head; 
Mhile (iin2 s (struct IntuiMessage *) 

iml->ExecMessage.ffln_Node.ln_Succ) 


( 


if (ini2->ExecMessage.mn_Node.ln_Succ « NULL) break; 



672 


Das große C-Buch zum Amiga 


if (im1->Class != RAUKEY) break; 
if (!(im1->Qualifier & lEQUALIFIER REPEAT)) break; 
if (iin2->Class 1= RAUKEY) break; 
if (Kim2->Qualifier & IEQUALIFIER_REPEAT)) break; 

/* Message entfernen: */ 
im1 = GetNsgCedUserPort); 

ReplyHsg(iml); 


> 


im1 - (struct IntuiMessage *) 

edUserPor t - >fnp_MsgL 1 s t. l h_Head; 


break; 

> 


Als letztes zu erwähnen wäre, daß hinter der Switch-Case-An- 
weisung noch folgende Funktion aufgerufen werden muß: 

savelfCursorMovedC); 

Diese Funktion muß als void deklariert werden. Wenn Sie jetzt 
noch in der Make-Datei zur Liste der Objektdateien (OBJ) 
Edit.o hinzunehmen und folgende Zeile ans Ende der Make-Da¬ 
tei anfügen: 

src/Edit.o: src/Edit.c src/Editor,h /pre/Editor.pre 

sind wir auch schon fertig. Alle Quell texte und den bereits 
übersetzten Editor finden Sie im Verzeichnis V0.5 auf der Dis¬ 
kette zum Buch. Beginnen Sie also gleich mit dem Ausprobieren. 
Sie haben diesmal ziemlich viel zu tun, da durch die vielen Op¬ 
tionen einiges zu testen ist. Einen Fehler, der uns bei der Pro¬ 
grammentwicklung untergekommen ist, haben wir auch diesmal 
wieder für Sie im Programm gelassen. Aber suchen Sie doch 
erstmal selbst danach. 

Haben Sie ihn gefunden? Wenn man im Überschreibmodus am 
Ende einer Zeile Zeichen anfügen will, so vergißt der Editor 
diese, sobald man die Zeile wieder verläßt. Nehmen wir an, wir 
haben uns den Quelltext bereits mehrfach angesehen, können 
aber keine fehlerhafte Stelle entdecken. Hier hilft dann nur noch 
der Debugger. Starten Sie also den Debugger DB und danach den 
Editor, so, wie wir es bereits zuvor beschrieben haben: 
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sys3:bin/db 

Editor <TestText 

Beachten Sie dabei, daß der Editor mittels "make Debug" erzeugt 
worden sein sollte, so wie der Editor, der sich im Verzeichnis 
V0.5 der Diskette zum Buch befindet. Der Debugger fängt den 
Editor dann wie gewohnt ab. Nun gilt es zu überlegen, wie wir 
weiter Vorgehen. Der Fehler tritt auf, wenn wir ein Zeichen am 
Ende einer Zeile anfügen wollen, also voraussichtlich in der 
Funktion insertChar. Setzen Sie also zunächst einen Breakpoint 
auf diese Funktion: 

bs insertChar 

und starten Sie dann den Editor mittels g (Go). Aktivieren Sie 
das Editorfenster, und drücken Sie nun Ctrl-0, um in den 
Überschreibmodus zu gelangen. Suchen Sie sich dann eine pas¬ 
sende Zeile aus, am besten eine, in der noch gar nichts steht. 
Bewegen Sie den Cursor dorthin, und drücken Sie eine Taste, 
also z.B. das a. Der Editor wird unterbrochen, und der Debugger 
zeigt Ihnen den Beginn des Unterprogramms insertChar an. Jetzt 
brauchen Sie nur noch den Fehler zu finden! Die Ursache dafür 
könnte z.B. darin liegen, daß die Länge des Puffers nicht kor¬ 
rekt erhöht wird, wenn Sie ein Zeichen anfügen wollen. Am be¬ 
sten, Sie gehen nun im Einzelschrittmodus durch diese Funktion, 
vielleicht fällt Ihnen dabei ja etwas auf. 

Zuerst kommt die übliche Initialisierung der Funktion mit LINK 
und MOVEM. Dann wird das einzufügende Zeichen nach Regi¬ 
ster D4 geschrieben, es handelt sich ja um eine Registervariable. 
Weiterhin wird die lokale Variable -a(A5) mit dem Wert Eins 
gefüllt, was darauf schließen läßt, daß es sich dabei um xadd 
handelt. Dann wird getPuffer Pointer auf gerufen, was Sie bitte 
im Debugger mittels t überspringen, anstatt den Befehl s zu be¬ 
nutzen. Im Gegensatz zum Einzelschrittbefehl s führt t nämlich 
einen Befehl komplett aus, also wird bei einem Unter¬ 
programmaufruf mittels BSR oder JSR das gesamte Unterpro¬ 
gramm ausgeführt, bevor der Debugger wieder die Kontrolle 
über das Programm erhält. 
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Nun sehen wir uns die Werte an, die in die Variablen ptr, inc 
und rest geschrieben wurden: 

p2clX a5-8 

Wie kommen wir denn nun darauf? Vor dem Aufruf der Funk¬ 
tion getPufferPointer wurden drei Adressen auf den Stack ge¬ 
legt, die die Adressen der drei gesuchten Variablen sind: 

-8<a5) 

-6<a5) 

-4(a5) 

Da in C Variablen beim Funktionsaufruf immer in der Reihen¬ 
folge auf dem Stack liegen, in der sie definiert wurden, können 
wir folgende Zuordnung treffen: 

rest = -8(a5) 
inc = -6(a5) 
ptr = -4(a5) 

Diese wollen wir nun ausgeben lassen. Dazu ist es am einfach¬ 
sten, ab Adresse -8(a5) zuerst zwei Wörter und dann ein Lang- 
word ausgeben zu lassen, was in der Syntax des Debuggers p2dX 
heißt, also Print zweimal Dezimal und einmal Hexadezimal- 
Langwort, gefolgt von der Anfangsadresse. Die Werte für inc 
und rest sind beide Null, wenn Sie den Cursor auf eine leere 
Zeile bewegt hatten. Der Wert von ptr ist uninteressant, aber 
lassen Sie sich doch mal zeigen, worauf ptr zeigt: 

db *05-4) 

Sie sehen nun eine Zeile im Debugger-Fenster, die aus einer 
Adresse, einem Gleichheitszeichen und lauter "20" besteht. Der 
ptr zeigt also auf einen String, der nur aus Blanks (= $20) be¬ 
steht. Doch lassen Sie den Debugger nun weiter einzelschritt¬ 
weise laufen, denn bis jetzt war ja alles richtig. Es folgt das Te¬ 
sten des Rückgabewertes, und dann wird überprüft, ob D4 den 
Wert 9 enthält. D4 ist das einzufügende Zeichen, und 9 ent¬ 
spricht einem Tabulator. Da Sie aber einen normalen Buchstaben 
gedrückt haben, springt das Programm weiter. 
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Jetzt wird ein Wert aus der Editor-Struktur geholt und davon 
das erste Bit ausmaskiert und getestet. War dies Null, so befindet 
sich der Editor im Oberschreibmodus, und der Editor springt 
wieder weiter. Sie haben hoffentlich das Treiben des Debuggers 
mit dem Programmtext verglichen und wissen nun, wo wir sind. 
Wenn Sie sich das Programm von dieser Stelle ab disassemblieren 
lassen, so sollten Sie folgendes sehen: 


insertChar+184 

insertChar-i-ISS 

insertChar**’18a 

insertChar-t'ISe 

insertChar+190 

insertChar+194 

insertChar+198 

insertChar*»*19e 


movea.l -4(a5),a0 
move.b d4,(a0) 
clr.w -8(a5) 
beq.s _insertChar+19e 
movea.l _aktueUerEditor,aO 
addq.w #1,76(a0) 
move.w #1,-8(a5) 


Dieses kurze Programmstück entspricht folgenden Zeilen, die in 
unserer Funktion insertChar für das Einfügen von Zeichen im 
Überschreibmodus sorgen und die Sie am Ende der Funktion 
finden: 


♦ptr = c; 
if (rest a 0) 

< 

aktuel lerEdi tor->puf lerv»"**; 
rest =1; 

> 

Zuerst wird also das Zeichen an die Stelle abgespeichert, auf die 
ptr zeigt. Dann sollte rest auf Null getestet werden, statt dessen 
wird die Speicherstelle -8(a5) auf Null gesetzt. Und hier liegt 
auch der Fehler. Statt (rest = 0) muß es (rest == 0) heißen. Diese 
Eigenart von C, Zuweisungen quasi überall hinschreiben zu kön¬ 
nen, also auch in Abfragen, erweist sich hier als Stolperstein. 
Aber damit muß man leben. Außerdem lassen sich dadurch auch 
recht trickreiche Befehle realisieren. 


Nun können Sie den Fehler korrigieren und das Programm 
nochmals übersetzen, wenn Sie wollen. Wir wollen uns an dieser 
Stelle einer Sache zuwenden, deren Sinn und Zweck nicht unbe¬ 
dingt einleuchtet, wenn man sich damit nicht schon näher befaßt 
hat. 
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Gemeint sind lokale Variablen in Blöcken. Was ein Block ist, 
wissen Sie ja: eine Folge von Befehlen, die durch geschweifte 
Klammern eingefaßt sind. Lokale Variablen definiert man für 
gewöhnlich am Anfang eines Blocks. Wir haben lokale Variablen 
immer nur im Zusammenhang mit Funktionen in Programmen 
gefunden. Es wurden also zu Beginn einer Funktion deren lokale 
Variablen definiert. Dabei kann man in jedem Block lokale Va¬ 
riablen definieren. Nun fragen Sie wahrscheinlich, und nicht 
ganz zu Unrecht, welchen Sinn dies haben sollte. 

Solange es sich bei den Variablen nicht um Register-Variablen 
handelt, haben lokale Variablen eigentlich nur den Zweck, die 
Variablenstruktur etwas übersichtlicher zu gestalten. Das Pro¬ 
blem mit Register-Variablen ist, daß Sie nur eine begrenzte 
Anzahl von Registern zur Verfügung haben, in der Regel 5 bis 
7. Dieses läßt sich durch lokale Variablen in Blöcken geschickt 
umgehen. Dazu definieren Sie Register-Variablen nur in dem 
Block, in dem Sie diese wirklich benötigen; notfalls packen Sie 
alle betroffenen Anweisungen in einen neuen Block. Außerhalb 
des Blockes sind die entsprechenden Register nun frei und kön¬ 
nen vom C-Compiler anderweitig vergeben werden. Ihr Pro¬ 
gramm wird dadurch schneller, da mehr Register-Variablen ge¬ 
nutzt werden können. Betrachten Sie dazu die beiden Funktionen 
slow und fast: 

slowO 

i 


regiSter 

int 

a.b.c; 



regiSter 

int 

a1,b1,c1; 



regiSter 

int 

a2,b2,c2; 



for (a1 = 

# 

' a. 

b1 = b, c1 = c; 

a1 > 0; 

a1--) 

for (a2 = 

' a. 

b2 = b, c2 = c; 

a2 > 0; 

a2--) 


> 

fastO 

i 


reg1 Ster int a,b,c; 
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register int a1,b1,c1; 

for (a1 = a, bl = b, c1 = c; a1 > 0; a1--) 

f 

> 

c 

register int a2,b2,c2; 

for (a2 = a, b2 = b, c2 = c; a2 > 0; a2--) 

$ 

> 

> 

Diese erfüllen beide denselben Zweck, auch wenn dieser sinnlos 
ist. Es kommt hier nur darauf an, daß relativ viele Register-Va¬ 
riablen verwendet werden. Compilieren Sie diese Funktionen, so 
erhalten Sie folgenden Assembler-Quelltext: 

;slow() 

public _slow 
_slow: 

link a5,#.2 
movem.l .3,-(sp) 

; register int a,b,c; 

; register int a1,b1,c1; 

; register int a2,b2,c2; 

; for (a1 = a, b1 = b, c1 = c; a1 > 0; a1--) 

move.w cl4,d7 
move.w d5,a2 
move.w d6,a3 
bra .7 

.6 

$ t 

A 

sub.w #1,d7 
.7 

tst.w d7 
bgt .6 
.5 

i 

; for (a2 » a, b2 - b, c2 > c; a2 > 0; a2--) 

move.w d4,-2(a5) 
move.w d5,-4(a5) 
move.w d6,*6(a5) 
bra .11 

.10 


.8 


sub.w #1,*2(a5) 
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.11 

tst.w -2(a5) 
bgt .10 
.9 

0 

;> 

.12 

movem.l (spH^.B 

unlk a5 

rts 

.2 equ -6 

.3 reg Cl4/d5/d6/d7/a2/a3 


;fast() 

:< 

public _fast 
fast: 

link a5.#.13 
movem.l .14,-(sp) 

; register int a,b,c; 

0 

; i 

; register int a1,b1,c1; 

0 

; for (a1 » a, bl » b, c1 * c; a1 > 0; a1--) 

move.w d4,d7 
move.w d5,a2 
move.w d6,a3 
bra .18 
.17 

0 0 
.15 

sub.w #1,d7 

.18 

tst.w d7 
bgt .17 


; i 

; register int a2,b2,c2; 

0 

; ' for (a2 = a, b2 = b, c2 = c; a2 > 0; a2--) 

move.w d4,d7 
move.w d5,a2 
move.w d6,a3 
bra .22 

.21 

0 0 
.19 

sub.w #1,d7 

.22 

tst.w d7 
bgt .21 
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.20 

; > 

;> 

.23 

movem.l (sp)+,.14 

unlk a5 

rts 

.13 equ 0 

.14 reg d4/d5/d6/d7/a2/a3 
dseg 
end 

Hier kommt es jetzt nur auf die Umsetzung der Zuweisungen 
an, da man an diesen erkennen kann, welche Variablen Regi¬ 
ster-Variablen sind und welche nicht. In der Funktion slow se¬ 
hen Sie in der ersten For-Schleife lauter Register, aber in der 
zweiten For-Schleife werden die Werte der Register in den 
Speicher geschrieben. Hier wurden zu viele Register-Variablen 
definiert, so daß der C-Compiler einige davon als ganz normale 
Variablen umsetzen mußte. Anders dagegen die Funktion fast: 
Hier sind alle Variablen Register-Variablen, was sich angenehm 
auf die Laufzeit dieser Funktion auswirken würde. 

Wir haben in den neuen Funktionen, die zu unserem Editor 
hinzugefügt wurden, von der Möglichkeit, lokale Variablen in 
Blöcken zu definieren, bereits Gebrauch gemacht. Wir werden 
dies auch in Zukunft tun, damit der Editor recht flott wird. Ex¬ 
perimentieren Sie doch auch mal damit. Vielleicht fallen Ihnen 
auch noch andere Möglichkeiten ein, ein Programm schneller zu 
machen, ohne daß der Programmtext unlesbar wird. Das Einbin¬ 
den von Assembler-Unterprogrammen wäre eine solche Mög¬ 
lichkeit, die sich aber nur für denjenigen eignet, der sich mit 
Assembler ein bißchen auskennt. Denn ein Vorteil von As¬ 
sembler ist, daß Sie jederzeit mit 15 Registern jonglieren und 
deren Bedeutung für das Programm an jeder Stelle ändern kön¬ 
nen, sofern der ursprüngliche Inhalt des Registers nicht mehr 
benötigt wird! 
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4.3.9 Kommandozeile 

Die Möglichkeit, Texte abzuspeichern und zu laden, haben wir 
bis jetzt an unserem Editor schmerzlich vermißt. Da wir dies 
nicht über Control-Codes veranlassen können - schließlich müs¬ 
sen wir einen Dateinamen angeben -, brauchen wir eine soge¬ 
nannte Kommandozeile, wie sie auch Ed aufweist. 

Ferner wollen wir bei der Gelegenheit auch gleich eine Status¬ 
oder Infozeile einbauen, in der der Editor die Cursor-Position 
und andere Informationen anzeigt. 

Doch zunächst wollen wir uns mit der Kommandozeile beschäf¬ 
tigen. Diese soll in etwa so funktionieren wie die von Ed, die 
Aktivierung soll durch Escape geschehen und sie soll vorwiegend 
Befehle enthalten, die sich aus zwei Buchstaben zusammensetzen. 
Bei Ed hat uns aber gestört, daß Befehle, die zu einer Gruppe 
gehören, also z.B. Blockbefehle, nicht immer gleich aufgebaut 
sind. So lautet der Befehl zum Markieren des Blockanfangs BS, 
aber zum Einfügen des Blocks in den Text muß man IB einge¬ 
ben statt BI oder BC (Block Copy). Ed zählt IB zu den Insert- 
Befehlen, was sicher auch richtig ist, aber über Geschmack läßt 
sich ja bekanntlich nicht streiten. 

Wir wollen unsere Befehle so benennen, daß deren erster Buch¬ 
stabe Auskunft über die Befehlsgruppe gibt, zu der dieser Befehl 
gehört. Überlegen wir uns nun, welche Befehlsgruppen uns für 
unseren Editor einfallen. 

Da wären zuerst die bereits erwähnten Block-Befehle. Ferner 
brauchen wir Befehle zur Cursor-Steuerung, zum Abspeichern 
und Laden, zum Setzen der Flags, zum Löschen, zum Suchen 
und Ersetzen, und um das Programm wieder zu verlassen. 

Auch brauchen wir Befehle um den Editor programmieren zu 
können; Sie erinnern sich: Wir sprachen zu Beginn der Pro¬ 
grammplanung darüber. Im folgenden nun eine Auflistung der 
Befehle, die uns eingefallen sind: 
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ASCII-Berehk 


AF ["Dateiname"] 

AL ["Dateiname") 

AS ["Dateiname") 

Abspeichem des Textes einer Falte. 

Laden eines Textes. 

Abspeichem des gesamten Textes. 

Block-Befehle 


BC (Block Copy) 

BD (Block Delete) 

BE (Block End) 

BF (Block Fold) 

BH (Block Hide) 

BM (Block Move) 

BP (Block Paste) 

BS (Block Start) 

BX (Block Cut) 

Block kopieren. 

Block löschen. 

Blockende markieren. 

Block wegfalten. 

Markierung löschen. 

Block verschieben. 

Block aus Puffer kopieren. 

Blockanfang markieren. 

Block in Puffer kopieren (ausschneiden). 

Cursor-Befehle 


CB (Cursor Bottom) 

CD (Cursor Down) 

CE (Cursor End) 

CH (Cursor Home) 

CL (Cursor Left) 

CN (Cursor Next) 

CP (Cursor Previous) 

CR (Cursor Right) 

CS (Cursor Start) 

CT (Cursor Top) 

CU (Cursor Up) 

Cursor auf Text-/Faltenende. 

Cursor um eine Zeile nach unten. 

Cursor hinter Zeilenende setzen. 

Cursor auf Zeilenanfang setzen. 

Cursor ein Zeichen nach links. 

Cursor auf Anfang von nächster Zeile. 

Cursor auf Anfang von voriger Zeile. 

Cursor ein Zeichen nach rechts. 

Cursor auf Zeilenanfang setzen. 

Cursor auf Text-/Faltenanfang. 

Cursor um eine Zeile nach oben. 

Delete-Befehle 


DB (Delete Back) 

DC (Delete Char) 

DL (Delete Line) 

Backspace. 

Zeichen löschen (Delete). 

Zeile löschen. 

Exchange-Befehle (Ersetzen) 


EN ("Stringl"String2"] 

EP ("Stringl"String2"] 

Ersetze nächstes Vorkommen. 

Ersetze voriges Vorkommen. 

Find-Befehle (Suchen) 



FN ("String"] 
FP ("String") 


Suche nSchstes Vorkommen von String. 
Suche rückw&rts. 
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IF-Befehl 


IF (Bedingung) Anweisung 

Line-Befehle (Zeilen) 


LA "String" 

Füge String als neue Zeile hinter (Append) 
aktueller Zeile in den Text ein. 

LI "String" 

Füge String als neue Zeile vor (Insert) 
aktueller Zeile in den Text ein. 

LJ (Line Join) 

Füge Zeile mit folgender zusammen. 

LS (Line Split) 

Trenne Zeile an Cursor-Position auf. 

Makro-Befehle 

M[A-Z] [=Anweisungsfolge] 

Makro ausführen bzw. setzen. 

(}uit-Befehl 

Q 

Verlasse Editor. 

Repeat-Befehl 

RP Anweisung 

Wiederhole Anweisung bis Abbruch. 

Set-Befehle 

Sa 

Auto-Indent aus. 

SA 

Auto-Indent ein. 

Sb 

SkipBlanks aus. 

SB 

SkipBlanks ein. 

Si 

Einfügemodus (Insert). 

So 

Überschreibmodus (Overwrite). 

St 

Tabulatoren aus. 

ST 

Tabulatoren ein. 

Tabulator-Befehle 

TC (Tab Clear) 

Lösche Tabulator an Cursor-Position. 

TS (Tab Set) 

Setze Tabulator an Cursor-Position. 

eXit-Befehl 

X 

Text abspeichern, falls verändert, und Pro¬ 
gramm beenden. 

Undo-Befehl 

U 

Änderungen in aktueller Zeile rückgängig 
machen. 
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Außer bei den Set-Befehlen kommt es übrigens nicht darauf an, 
ob ein Befehl groß oder klein geschrieben wurde! Wir werden 
allerdings nicht alle diese Befehle auf einmal einbauen, sondern 
zunächst nur die wichtigsten: das Abspeichern und Laden von 
Text sowie die Befehle, für die wir bereits Funktionen pro¬ 
grammiert haben, wie z.B. die Cursor-Bewegung. 

Um die Befehle eingeben zu können, brauchen wir eine Kom¬ 
mandozeile, die unabhängig von den normalen Editierfunktionen 
arbeitet. Wir werden dafür ein String-Gadget benutzen, das wir 
in die untere Kante des Fensters legen. Damit wir es nicht je¬ 
desmal mit der Maus aktivieren müssen, lassen wir es vom Edi¬ 
tor aktivieren, sobald die ESC-Taste gedrückt wird. Sie werden 
dann in der Bedienung keinen Unterschied zu dem Editor Ed 
bemerken, außer dem, daß Sie in der Kommandozeile auch edi¬ 
tieren können. 

Nun muß der Editor die Befehle der Kommandozeile ausführen, 
sobald wir diese mit Return bestätigt haben. Damit der Editor 
dies bemerkt, setzen wir das RELVERIFY-Flag. Der Editor be¬ 
kommt dann jedesmal eine GADGETUP-Message, wenn Sie im 
String-Gadget Return drücken. Er muß dann entscheiden, wel¬ 
cher Befehl eingegeben wurde, und die entsprechende Funktion 
aufrufen. Da wir eine ganze Menge an Befehlen haben, wäre es 
zu umständlich, die Kommandozeile mit allen bekannten Befeh¬ 
len zu vergleichen. Aber unsere Befehle sind ja nach Gruppen 
sortiert, und alle Befehle einer Gruppe beginnen mit demselben 
Buchstaben. Wir werden also zunächst nach dem ersten Buchsta¬ 
ben der Kommandozeile die Befehlsgruppe bestimmen, zu der 
der Befehl gehört, und dann eine entsprechende Funktion auf¬ 
rufen, die bestimmt, um weichen Befehl es sich handelt, und die 
diesen dann ausführt. 

An diese Funktion wird ein Zeiger auf den zweiten Buchstaben 
des Befehls übergeben, da der erste ja bereits erkannt wurde. 
Wenn die Funktion den Befehl ausführen konnte, so gibt diese 
einen Zeiger auf das Zeichen hinter dem Befehl zurück, an¬ 
dernfalls eine entsprechende Fehlermeldung. Auf gerufen werden 
diese Funktionen von der Funktion executeCommand aus. Diese 
überspringt nicht nur Blanks und überprüft, ob zwei Befehle 
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auch wirklich durch ein Semikolon voneinander getrennt wur¬ 
den, sondern führt Befehle mehrfach aus, wenn eine Zahl vor 
dem Befehl stand. 

Auch ist es erlaubt, mehrere Befehle durch geschweifte Klam¬ 
mern zu klammern und vor diese Klammern eine Zahl zu 
schreiben. Die eingeklammerten Befehle werden dann so oft aus¬ 
geführt, wie die Zahl angibt. Folgende Befehlszeile würde z.B. 
die aktuelle und weitere neun Zeilen um jeweils drei Zeichen 
nach links rücken: 

CS;10<3OC;CD};10CU 

Anschließend würde der Cursor wieder auf die Ursprungszeile 
gesetzt werden. Aber diese Funktion muß noch zwei weitere 
Dinge beachten: Nachdem ein Befehl ausgeführt worden ist, muß 
die Funktion saveIfCursorMoved aufgerufen werden, da der 
Cursor ja möglicherweise bewegt worden ist. Ferner muß eine 
Befehlsfolge abbrechbar sein, damit man im Falle einer Fehlpro¬ 
grammierung nicht zuviel von seinem Text verliert. Abgebrochen 
wird, sobald der Benutzer irgendeine Taste gedrückt hat. 

Wenden wir uns jetzt der Infozeile zu. Damit diese nicht eine 
ganze Zeile belegt, werden wir diese neben die Kommandozeile 
in die untere Fensterkante legen. Damit sie nicht zu breit wird, 
wollen wir uns auf die wichtigsten Anzeigen beschränken: X- 
und Y-Position des Cursors, Anzahl der Zeilen, minfold, max- 
fold und die Flags. Schränken wir die maximale Breite für die 
einzelnen Zahlen auf vier Zeichen ein (zwei Zeichen für min¬ 
fold bzw. maxfold), so kommen wir mit 34 Zeichen aus: 

X=nnnn Y=nnnn #=nnnn [nn,nnl ICATB 

wobei # für die Anzahl der Zeilen steht. In der eckigen Klam¬ 
mer entspricht die erste Zahl minfold und die zweite maxfold. 
Bei den Flags werden kleine Buchstaben angezeigt, wenn diese 
nicht gesetzt sind, und große, wenn doch. Dabei gilt folgende 
Zuordnung zwischen Buchstaben und Flags: 
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I: insert (0 = Overwrite), 

C: changed. 

A: autoindent. 

T: tabs. 

B: skipblanks. 

Damit sich die Infozeile nicht mit der Kommandozeile über¬ 
schneidet, wenn das Fenster verkleinert wird, setzen wir die 
Breite der Kommandozeile relativ zur Fensterbreite. Dann müs¬ 
sen wir die minimale Breite des Fensters allerdings heraufsetzen, 
da sonst die Kommandozeile eine negative Breite bekommen 
würde, wenn man das Fenster zu klein machen würde. 

Um nun die Werte in der Infozeile auszugeben, können wir 
nicht jedesmal die gesamte Infozeile neu ausgeben, da dies zu 
lange dauern würde. Statt dessen schreiben wir Funktionen, die 
jeweils einen Wert bzw. eine Gruppe von Werten ausgeben. Da 
es vor allem bei der Ausgabe der Cursor-Position auf Schnellig¬ 
keit ankommt, wollen wir diese Gelegenheit nutzen, um ein 
Unterprogramm in Assembler zu schreiben und in unser Pro¬ 
gramm einzubinden. Damit das Assembler-Programm nicht allzu 
schwierig wird, wollen wir die Konvertierung einer Zahl in eine 
Zeichenkette in Assembler programmieren. 

Die C-Bibliothek stellt uns für diesen Zweck zwar die Funktion 
ftoa zur Verfügung, diese verlangt aber eine Floating-Point- 
Zahl. Der C-Compiler würde also unsere Integer-Zahl erst in 
eine Floating-Point-Zahl umwandeln und diese dann konvertie¬ 
ren. Unsere Funktion wird dagegen direkt eine Integer-Zahl 
konvertieren, wobei wir auch noch festlegen können, wie lang 
die Zeichenkette maximal sein darf. 

Das Einbinden von Assembler-Programmen ist nun beim Aztec 
kein Problem. Statt des Funktionskopfes schreiben wir zuerst die 
Compileranweisung #asm an den Anfang einer Zeile. Dann ge¬ 
ben wir unser Assembler-Programm ein und beenden dieses mit 
einem #endasm. Der Compiler weiß dann, daß zwischen #asm 
und #endasm ein Assembler-Programm liegt und überliest dies 
bei der Übersetzung. Erst beim nachfolgenden Übersetzen mit 
dem Assembler, was ja vom C-Compiler automatisch gestartet 
wird, wird das Assembler-Programm mit übersetzt. Damit wir 
das Unterprogramm auch von unseren C-Funktionen aus aufru- 
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fen können, müssen wir die Adresse des Unterprogramms dem 
Linker bekannt machen. Wollen wir unser Unterprogramm mit 
dem Namen cn_utoa aufrufen (CoNvert Unsigned TO Ascii), so 
müssen wir folgende Zeilen an den Anfang des Unterprogramms 
schreiben: 

global _cn_utoa 
_cn_utoa: 

Der Befehl global macht das Label des Unterprogramms 
_cn_utoa dem Linker bekannt, so daß darauf wie auf eine glo¬ 
bale Variable oder eine Funktion zugegriffen werden kann. Der 
Unterstrich vor dem Funktionsnamen ist deswegen nötig, weil 
der C-Compiler, wenn er ein C-Programm in ein Assembler¬ 
programm übersetzt, vor alle Bezeichner einen Unterstrich setzt. 
Wenn Sie sich bereits angesehen haben, was für Assembler-Pro¬ 
gramme der C-Compiler erzeugt, so haben Sie dies sicher schon 
bemerkt. 

Die Übergabe der Parameter ist dabei so, wie Sie es erwarten 
würden: Die Parameter, die zuerst definiert werden, liegen oben 
auf dem Stack. Wenn wir unsere Funktion mit: 

cn_utoa(string,wert,laenge); 

aufrufen, so fänden wir die Parameter an folgenden Adressen 
auf dem Stack, wenn wert und laenge vom Typ UWORD sind: 

0(SP) * Rücksprungadresse. 

4(SP) ■ String. 

8(SP) s wert. 

10(SP) » laenge. 

Bei der Verwendung der Register in unserem Assembler-Pro¬ 
gramm dürfen wir nicht alle Register frei verwenden. Die Regi¬ 
ster, die der C-Compiler für Verweise auf lokale (A5) und glo¬ 
bale (A4) Variablen benutzt, dürfen ebensowenig verändert wer¬ 
den wie die Register, die bei Registervariablen verwendet wer¬ 
den (D4-D7, A2, A3). Aber uns bleiben noch genug Register 
übrig, vor allem, weil wir für unser Unterprogramm nur vier 
Stück benötigen. Hier nun unser Assembler-Unterprogramm: 
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#asm 

public _cn_utoa 
cn utoa: 


; 4(sp) * Puffer, 

; 8(sp) = Wert, 

;10(sp) ~ maximale Laenge. 


lea 

4(sp),a0 



move.l 

(a0)+,a1 



moveq 

#0,d0 



move.u 

(aO)*i-,dO 

i 

= Wert 

move.w 

(a0),d1 

§ 

= maximale Laenge 

lea 

0(a1,d1.w),a0 

« 

Ende des Puffers 

bra.s 

.in 



Ip: 




divu 

#10,dO 



suap 

dO 



add.b 

#*0*,d0 

t 

dO.u s Wert MOD 10 

move.b 

d0,-(a0) 



cir.u 

dO 



swap 

dO 

t 

Zero'Flag ist 1, wenn dO.l » 0 

in: 




dbeq 

cl1,.lp 

i 

solange bis Wert » o oder String voll 

beq.s 

.ib 

$ 

Wert = 0 s> 



i 

Rest mit Blanks auffuellen 

bra.s 

.r 

i 

String voll! 

bl: 




move.b 

#» *,-(a0) 



ib: 




dbra 

d1,.bl 




.r: 


rts 

#endasm 

Das Programm arbeitet so, daß der String von hinten gefüllt 
wird. Dabei wird die Zahl, die konvertiert werden soll, jedesmal 
durgh zehn dividiert, und der Rest, der bei der Division übrig¬ 
geblieben ist, wird als Ziffer in den String geschrieben. Zum 
Schluß wird noch der Rest des Strings mit Blanks aufgefüllt, 
sofern dafür noch Platz ist. 

Um die entsprechenden Werte in der Infozeile ausgeben zu kön¬ 
nen, benötigen wir noch die Position, an der diese ausgegeben 
werden müssen. Dazu addieren wir auf die Position des Gadgets, 
zu dem die Infozeile gehört, die Position der IntuiText-Struktur, 
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die die Infozeile enthält. Damit die Infozeile möglichst schmal 
wird, werden wir in der IntuiText-Struktur den Zeichensatz 
festlegen, in dem die Infozeile ausgegeben werden soll. Hier 
empfiehlt sich TopazSO, der 80 Zeichen pro Zeile erlaubt. 

Nun müssen wir bei der Ausgabe der Werte aber auch diesen 
Zeichensatz wählen. Wenn wir die Intuition-Funktion PrintIText 
verwenden würden, so wäre dies kein Problem, da wir dann in 
der IntuiText-Struktur, die diese Funktion verlangt, den Zei¬ 
chensatz angeben könnten. Allerdings verlangt diese Funktion 
ein Null-Byte am String-Ende. Besser wäre es, wenn wir die 
Funktion Text aus der Graphics-Library benutzen, da man bei 
dieser die Länge der Zeichenkette angeben kann. Sie müssen 
bedenken, daß wir den Wert auch in den String der Infozeile 
kopieren müssen, da beim Neu-Ausgeben des Fensters auch 
dessen Umrandung neu ausgegeben wird. Würden wir nur den 
neuen Wert mittels "PrintIText" oder "Text" im Fenster über dem 
alten ausgeben, so erschiene beim Neu-Ausgeben wieder der alte 
Wert, da sich dieser immer noch im String befände. 

Wir werden also den neuen Wert (xpcs, ypos, etc.) in die Info¬ 
zeile kopieren bzw. konvertieren und dann den entsprechenden 
Ausschnitt der Infozeile mittels "Text" ausgeben. Dazu müssen 
wir aber zuvor den Zeichensatz mit SetFont einstellen. Und da¬ 
für wiederum müssen wir im Hauptprogramm den Zeichensatz 
mit OpenFont öffnen, damit wir überhaupt auf diesen zugreifen 
können. Die Funktionen zur Ausgabe der Werte der Infozeile se¬ 
hen wie folgt aus (Das Assembler-Programm _cn_utoa sollten 
Sie vor diesen Funktionen in das Modul Ausgabe schreiben!); 

* 

* printXpos: 

* 

* Gibt Xpos des Cursors aus. 

* 

***************************** f 

void printXposO 
C 

register struct TextFont *oldFont; 
register struct Editor *ae » aktuellerEditor; 
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cn_utoa(ae->gi_Text + INFO^XPOSJNC, 

ae- >xpos, (UWORD ) IN FO_XPOS_LEN ) ; 

oldFont = ae->rp->Font; 

SetFont(ae->rp,infoFont); 

Move(ae->rp,ae->ip xpos,ae->ip topedge); 

Text(ae->rp,ae->gilText + INFOlxPOSJNC,(ULONG)INFO_XPOS_LEN); 
SetFont(ae->rp,oldFont); 


y***************************** 

* 

* printYpos: 

* 


* Gibt Ypos des Cursors aus. 

* 

***************************** y 


void printYposO 

< 

register struct TextFont *oldFont; 
register struct Editor *ae » aktuellerEditor; 

cn utoa(ae->gi Text ^ INFO YPOS INC, 

ae->ypos, (UWORD )INFO_YPOS_LEN); 


oldFont = ae->rp->Font; 

SetFont<ae->rp,infoFont); 

Move(ae->rp,ae->ip ypos,ae->ip topedge); 

Text(ae->rp,ae->gi”Text ^ INF0“yP 0SJNC,(UL0NG)INF0_YP0S_LEN); 
SetFont(ae->rp,oldFont); 


y***************************** 

* 

* printAnzZeilen: 

* 

* Gibt gesamte Anzahl der 

* Zeilen aus, aus denen der 

* Text besteht. 

* 


void printAnzZei lenO 
i 

register struct TextFont *oldFont; 
register struct Editor *ae « aktuellerEditor; 

cn utoa(ae->gi Text INFO ANZZEILEN INC,ae->anz Zeilen, 
(UWORD)INFO_ANZZEILEN_LEN); “ 

oldFont s ae->rp->Font; 

SetFont(ae->rp,infoFont); 

Move(ae-> rp,ae->ip_anzzeilen,ae->ip_topedge); 
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Text(ae->rp,ae->gi Text + IMFO_AMZZEILEM_IMC, 
(ULONG)INF0_ANZZEILEN_LEN); 

SetFont(ae~>rp,oldFont); 


y******************************** 

* 

* printFold; 

Sr 

* Gibt minfold und maxfold aus. 

* 

*****Sr***Sr**********Sr***********^ 


void printFoldO 
i 

register struct TextFont *oldFont; 
register struct Editor *ae * aktuellerEditor; 

cn_utoa(ae->gi Text + INFO MINFOLD INC,ae->minfold, 
(UW0RD)INF0_MINF0LD_LEN); ~ 
cn utoa(ae->gi Text INFO MAXFOLD INC,ae->inaxfold, 
(UW0RD)INF0_MAXF0LD_LEN); ~ 

oldFont * ae->rp->Font; 

SetFont(ae->rp,infoFont); 

Move(ae->rp,ae->ip_minfold,ae->ip^topedge); 
Text(ae->rp,ae->gi Text + 

IN FO.MINF0LD_INC,(ULONG)IN F0_MIN FOLD.LEN); 
Move(ae*>rp,ae->ip^maxfold,ae->ip_topedge); 
Text<ae->rp,ae->gi Text ♦ 

IN FO^MAXFOLD^INC,(ULONG)INFO^MAXFOLD^LEN); 

Set Font (ae->rp7oldFonO; ~ ~ 

> 


^*********Sr******************* 

* 

^ printFlags: 

* 

* Gibt Ypos des Cursors aus. 

* 


void printFlagsO 
C 

register struct TextFont *oldFont; 

register struct Editor *ae « aktuellerEditor; 

register UBYTE *fs * ae->gi_Text ♦ INFO_FLAGS_INC; 

if (ae->insert) 

♦f* •I•; 

eise 

♦fs-l”»- a »O*; 
if (ae->changed) 

*fs***+ a *C*; 
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eise 

*fs++ = *c*; 
if (ae->autoindent) 

*fs++ = *A*; 
eise 

*fs++ = *a*; 
if (ae->tabs) 

*fs+'»- = *T'; 
eise 

*fs++ = *t»; 
if (ae’>skipblanks) 

*fs = *B*; 
eise 

*fs = ‘b*; 

oldFont = ae->rp->Font; 

SetFont(ae->rp,infoFont); 

Move(ae-> rp,ae->ip_flags,ae->ip_topedge); 
Text(ae->rp,ae->gi Text ♦ 

INFO_FLAGS_INC,(ULONG)INFO_FLAGS_LEN); 
SetFont(ae’>rp,oldFont); 

> 


y**************************** 

* 


printInfo: 


* Gibt ganze Infozeile aus. 

* 

**************************** j 


void printlnfoO 
C 

printXposO; 
printYposO; 
printAnzZeilen(); 
printFoldO; 
printFlagst); 

> 

Alle Funktionen sind eigentlich gleich aufgebaut: Zuerst wird 
der neue Wert in den String kopiert, dann wird auf den Zei¬ 
chensatz umgeschaltet und der Teil der Infozeile neu ausgege¬ 
ben, der geändert wurde. Anschließend wird wieder auf den 
normalen Zeichensatz zurückgeschaltet. Die Positionen der ein¬ 
zelnen Werte werden dabei einmal aus den Defines und zum an¬ 
deren aus ein paar neuen Elementen der Editor-Struktur berech¬ 
net. Diese neuen Elemente, die die Pixel-Positionen aller Werte 
beinhalten, werden in initWindowSize initialisiert. Die neuen 
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Defines werden wir in Editor.h definieren, so daß wir im Modul 
Ausgabe nur die neue Funktion SetFont deklarieren müssen: 

void SetFont(); 

Ferner brauchen wir einen Zeiger auf den Zeichensatz, in dem 
die Infozeile ausgegeben wird und der im Hauptmodul definiert 
und geöffnet wird: 

extern struct TextFont *infoFont; 

In der Funktion initWindowSize müssen nun die Positionen der 
einzelnen Werte der Infozeile berechnet werden. Dies geschieht 
vor dem Restaurieren des zeilenptr-Feldes: 


/* Positionen fuer InfoZeile: V 
regiSter ULONG xinc,xsize; 


xinc = W’>Uidth + ed->G_Info.LeftEdge + 

ed->gi_IText.LeftEdge - 1; 

xsize- infoFont->tf_XSize; 


> 


ed->ip_xpos 

ed->ip_ypos 

ed->ip_anzzeilen 

ed->ip_minfold 

ed->ip_inaxfold 

ed->ip"flags 

ed->ip_topedge 


= xinc * INFO XPOS INC * xsize; 

= xinc + INF0“yP0s'“iNC * xsize; 

= xinc INFO^’anZZEILEN INC * xsize; 
= xinc + INFO~MINFOLDJNC * xsize; 

= xinc INF0_MAXF0LD INC * xsize; 

= xinc ♦ INFO^FLAGS.INC * xsize; 

= w->Height + ed->G_Info.TopEdge 
ed->gi_IText.TopEdge 
♦ <ULONGTinfoFont->tf_Baseline - 1; 


Damit wären die Änderungen im Modul Speicher abgeschlossen. 
Die Gadgets für die Info- und die Kommandozeile werden im 
Hauptmodul Editor definiert. Doch zunächst wollen wir uns das 
neue Modul Command ansehen: 


<src/co(nmand.c> 

y************************************ 
* * 

* Modul: Conmand * 

* * 

* Koninando-Interpreter für Editor. ♦ 
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* * 
*************4r**********************^ 


* 

* Includes: 

* 

************ j 

#include <stdio.h> 

#include <exec/types.h> 

#include <intuition/intuition.h> 
#include ”src/Editor.h” 

y*********** 

* 

* Defines: 

* 

***********y 

#define TAB 9 
#define LF 10 
#define CR 13 


#define UC(c) (((c >= 'a') && (c <= *z*))? (c & OxDF) : c) 
#define DIGIT(c) (<c >= *0') && <c <= *9*)) 

#define SKIPBLANKS(str) while (♦str == • •) str-»-+; 


^********************** 

* 

* Externe Funktionen: 

* 

********************** j 


BCX)L cursorLeft(),cursorRight(), 

cursorUpC),cursorDownC),cursorHome(); 

BOOL cursorEnd(),deleteChar(),deleteLine(), 

backspaceCharC),insertLine(); 

BOOL saveLineO; 

void printAll(),printFlags(),fclose(),Insert(), 

strncpy(),printAnzZei lenO; 
void restoreZeilenptr(),SetWindowTitlesO, 

initFolding(),printYpos(); 
void DisplayBeepC),savelfCursorMoved(),CopyMein(); 
struct Zeile ’^neueZeileO^^prevLineOj^nextLineO^- 
FILE *fopen(); 
int fwrite(),getc(); 

UBYTE *getLastWord(); 

ULONG fseekO; 

UWORD recalcTopOfWindow(); 
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y********************* 

* 


* Externe Variablen: 

* 

********************* f 


extern struct Editor *aktueUerEditor; 
extern struct MsgPort *edUserPort; 


^********************* 


* Globale Variablen: 

* 

********************* y 


Struct jmpEntry 

< 

UBYTE c; 

UBYTE *(*fkt)(); 


y*************** 

* * 

* Funktionen: 

* * 

*************** y 


y********************************* 

* 

* saveASCII(name) 

* 

* Speichert Text unter Namen auf 

* Diskette ab. 

* 

* name “ Dateinamen. 

* 

*********************************y 


BOOL saveASCII(name) 

UBYTE *name; 

< 

regiSter FILE *file; 
register struct Zeile ^z; 

if (aktuellerEditor*>pufypos) 

if (! saveLine(aktuellerEditor->aktuell)) 

DisplayBeep(NUL L); 
return (FALSE); 

> 

if (file =5 fopen(name,**w**)) 

C 

z s aktuellerEditor->zeilen.head; 
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while (z*>succ) 

< 

if (z->len) 

if (fwn’te(z + 1,(int)z->lenJ,file) != 1) 
C 

/* Fehler! V 
fclose (fUe); 
return (FALSE); 

> 

z = z->succ; 

> 

aktueUerEditor->changed = 0; 
printFlagsO; 
fclose (file); 
return (TRUE); 

> 

eise 

return (FALSE); 


^*********************************** 

* 

* loadASCIKname) 

* 

* Laedt Text von Disk. Der Text 

* wird hinter der aktuellen Zeile 

* in den Text eingefuegt. 

* 

* name * Dateinamen. 

* 


***********************************y 


BOOL loadASCIKname) 

UBYTE ’^name; 

i 

UBYTE buf[MAXBREITE]; 
register UBYTE *ptr,*tab; 
int c; 

UWORD rm = aktuellerEditor’>rm; 
register FILE *file; 
register UUORD len; 
register struct Zeile *z,*zn; 


if (file = fopen(name,**r”)) 
i 

/* Namen in Ti telzeile anzeigen: V 
strncpyCaktuel lerEditor’’>f f lename,name, 

sizeof(aktuellerEdftor->filename)); 
SetUindowTitlesCaktuellerEditor->window, 
aktuellerEditor->filename,-1L); 


if (z ZEILENPTR(aktuellerEditor->wdy)) 
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{ 

aktueUerEd1tor->changecl = 1; 
printFlagsO; 


while (!feof(file)) 

< 

tab = aktueUerEditor>>tabstring; 
ptr = buf; 
len = 0; 

/* Eine Zeile einiesen: V 
while (!feof(file) && (len < rm)) 

if ((c = getc(file)) == EOF) 
break; 
eise 

*ptr++ = <UBYTE)c; 

if ((c == TAB) && (aktuellerEditor‘>tabs)) 
do 
i 

tab4-+; 

len++; 

> while ((*tab) && (len < rm)); 
eise 
i 

tab+*»-; 

len++; 

if (c == LF) 
break; 

eise if (c == CR) 

if (Ifeof(file) && (len < rm)) 

< 

if ((*ptr = (UBYTE)getc(file)) « LF) 
ptr++; 
eise 

/* DateiZeiger zurueck setzen: V 
fseek(file,-lL,1); 

break; 

> 

> /* of if (TAB) V 
> /* of while V 

if (len = ptr - buf) 

C 

/* Wordwrap? */ 

if (laktuellerEditor->8kipblank8) 

if (den >:» rm) && (c I- CR) && (c LF)) 
i 

tab s getLa8tUord(buf,l^>; 

f8eek(file,(long)tab - ptr,1); 
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len = (ptr = tab) - buf; 

> 

/* Zeile nun abspeichern: V 
aktuellerEditor->lineptr = z; 

/* wg. Garbage-Collection ♦/ 
if (zn = neueZeile(len)) 
i 

z = alctuellerEditor->lineptr; 
zn->len = len; 

CopyMemCbuf,zn * 1,(UL0NG)len); 
aktuellerEditor->anz_zeilen++; 

Insert(&aktuellerEditor->zeilen,zn,z); 
z = zn; 

aktuellerEditor’>lineptr = NULL; 

> 

eise 

i 

aktuellerEditor->lineptr = NULL; 
fclose (file); 
return (FALSE); 

> 

> 

> 

/* Nun noch Falten-Level berechnen: V 
initFoldingO; 

/* Fenster neu ausgeben: V 
if ((ZEILENPTR(O) == NULL) && 

(aktuellerEditor->zeilen.head->succ)) 
i 

ZEILENPTR(O) = aktuellerEditor->zeilen.head; 

ZEILENNR(O) - 1; 

> 

restoreZeilenptrC); 
printAllO; 
printAnzZei lenO; 

fclose (file); 
return (TRUE); 

> 

eise 

return (FALSE); 


y************************************************* 

* 

* command-Funktionen: 

* 

* Diese bearbeiten jeweils eine Funktionsgruppe. 

* 

* Alle Funktionen liefern einen Zeiger auf den 

* naechsten Befehl zurueck, falls kein Fehler 




698 


Das große C-Buch zum Amiga 


* aufgetreten ist, andernfalls einen negativen 

* Zeiger auf das fehlerhafte Zeichen. 

«r 

* Liefert eine Funktion NULL zurueck, so gilt 

* dies als Abbruchkriterium. 

* 

* Eine -1 beendet das Programm. 

* 


UBYTE *commandASCII(str) 
regiSter UBYTE *str; 

C 

UBYTE *error = 1L - str,bufC80]; 
register UBYTE *name; 

switch (UC(*str)) 
i 

case *L*: 
str++; 

SKIPBLANKS(str) 
if (*str == *"*) 
i 

/* Hole Dateinamen aus Kommandozeile V 

str-»”»-; 

name » buf; 

while ((♦name * ♦str) && (♦str != •***) 

&& (name < buf sizeof(buf) - 1)) 
C 

name+**-; 

str+*»-; 

> 

♦name = 0; 
if (♦str == **••) 
str+'«-; 

name » buf; 

> 

eise 

/♦ Benutze Dateinamen vom Laden: ♦/ 
name * aktuellerEditor*>filename; 

if (KoadASCIKname)) 
return (error); 

break; 
case 'S': 
str-*”«'; 

SKIPBLANKS(8tr) 
if (♦str »* "") 
i 

/♦ Hole Dateinamen aus Kommandozei le ♦/ 
str-«‘+; 




Betriebssystemprogrammierung 


699 


name = buf; 

while ((*name = *str) && (*str != •”') 
&& (name < buf + sizeof(buf) - 1)) 

< 

name++; 

str++; 

> 

*name =0; 
if (*str == *«*) 
str++; 

name = buf; 

> 

eise 

/* Benutze Dateinamen vom Laden: V 
name = aktueUerEditor->f i lename; 

if (IsaveASCII(name)) 
return (error); 

break; 

default: 

return (NULL - str); 

> 

return (str); 

> 

UBYTE ’*'commandCursor(str) 
register UBYTE *str; 

i 

switch (UC(*str)) 

C 

case *R': 

if (icursorRightO) 
return (NULL); 
break; 
case *L‘: 

if (IcursorLeftO) 
return (NULL); 
break; 
case *U*: 

if (!cursorUp()) 
return (NULL); 
break; 
case 'D': 

if (!cursorDown()) 
return (NULL); 
break; 
case 'E': 

if (!cursorEnd()) 
return (NULL); 
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break; 
case 'S': 
case 'H': 

if (!cursorHomeC)) 
return (NULL); 
break; 
case 'N': 

if (icursorDownC)) 
return (NULL); 
if (!cursorHomeC)) 
return (NULL); 
break; 
case 'P': 

if (IcursorUp()) 
return (NULL); 
if (!cursorHome()) 
return (NULL); 
break; 
case 'T': 

if (IcursorTopO) 
return (NULL); 
break; 
case 'B': 

if (IcursorBottomO) 
return (NULL); 
break; 


default: 

return (NULL - str); 

> 


return (str + 1); 

> 


UBYTE *coiTinandDelete(str) 
reg i Ster UBYTE ’^str; 
i 

switch (UC(*str)) 


if (! deleteLineO) 
return (NULL); 
break; 
case 'C: 

if (! deleteCharO) 
return (NULL); 
break; 
case 'B': 

if (I backspaceCharO) 
return (NULL); 
break; 
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default: 

return (NULL - str); 

> 

return (str + 1); 

> 

UBYTE *coiiinandLine(str) 
reg1 Ster UBYTE *str; 

C 

switch (UC(*str)) 

C 

case *S': 

if (! insertLine((UBYTE) 0)) 
return (1 - str); 
break; 

default: 

return (NULL - str); 

> 

return (str + 1); 

> 

UBYTE *cofTvnandQuit(str) 
register UBYTE *str; 
i 

return (-1L); 

> 

UBYTE ♦coniiiandSet(str) 
register UBYTE ♦str; 
i 

switch (♦str) 
i 

case *t*: 

aktueUerEditor'>tabs = 0; 
printAllO; 
printFlagsO; 
break; 
case *T*: 

aktuellerEditor’>tabs = 1; 
printAlU); 
printFlagsO; 
break; 
case 'i': 
case 'I': 

aktuellerEditor’>insert = 1; 
printFlagsO; 
break; 
case * 0 *: 
case *0*: 

aktuellerEditor->insert = 0; 
printFlagsO; 
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break; 
case 'b': 

aktuellerEditor->skipblanks= 0; 
printFlagsO; 
break; 
case 'B': 

aktuellerEditor->skipblanks= 1; 
printFlagsO; 
break; 
case 'a': 

aktuellerEditor->autoindent= 0; 
printFlagsO; 
break; 
case 'A': 

aktuellerEditor->autoindent= 1; 
printFlagsO; 
break; 
case 'r*: 
case 'R': 

< 

regiSter UWORD rm; 
if (*++str == '=') 
i 

str++; 

if <DIGIT(*str)) 

C 

rm = 0; 

while (DIGIT<*str)) 

rm = 10*rm + (*str - *0*); 
str++; 

> 

if (rm > MAXBREITE) 
rm = MAXBREITE; 
eise if (rm < 10) 
rm = 10; 

> 

eise 

/* Fehler */ 
return (NULL - str); 

> 

eise 

rm = MAXBREITE; 

aktuellerEditor->rm = rm; 

--str; 

break; 


default: 

return (NULL - str); 

> 
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return (str + 1); 

> 

UBYTE *coninandExit(str) 
register UBYTE *str; 
i 

if (aktuellerEditor->changed) 

if (saveASCI I(alctueUerEditor->fi lename)) 
return (-1L); 
eise 

return (NULL - str); 

eise 

return (-1L); 

> 

UBYTE *executeComnand(); /* Deklaration wegen Rekurslon! V 

UBYTE *coninandBracket(str) 
register UBYTE *str; 

C 

register UBYTE *ptr; 

if (ptr = executeCommand(str)) 

if (ptr != -1L) 

if (ptr >= 0x80000000) 

/* Bestimme Zeiger auf Befehl hinter *>': V 
ptr = 1L - ptr; 
eise 

/* Zeiger auf Fehler: V 
ptr = NULL - ptr; 

> 

eise 

i 

/* Suche passendes '>•: V 
ptr = str; 

while (’^ptr && (*ptr != *>*)) 
i 

if (*ptr == *"*) 
do 
i 

ptr++; 

> while (’^ptr && (*ptr != '••*)); 
ptr++; 

> 

if (*ptr == 0) 
ptr = NULL; 
eise 
ptr-t-+; 

> 
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return (ptr); 


^**********4nllr**4r****4r************* 

* 

* messageUaiting: 

* 

* Testet, ob Message am UserPort 

* anliegt. 

* 

* Gibt TRUE zurueck, falls ja. 

* 

**************************4r******y 


BOOL messageWaitingO 
C 

register struct IntuiMessage *im; 

im = (struct IntuiMessage *)edUserPort->mp_MsgList.lh_Head; 
while (im->ExecMessage.mn Node.ln_Succ) 

C 

if ((im->Class == RAWKEY) 

&& !(im->Code & lECOOE UP PREFIX)) return (TRUE); 

if (im->Class == NEWSIZE)'’return (TRUE); 

im = (struct IntuiMessage *)im->ExecMessage.mn Node.ln_Succ 

> 


return (FALSE); 

> 

struct jmpEntry jmpTableC] = 
i 

'A*,&commandASCII, 

'C *,&commandCursor, 

'D',&commandDelete, 

■L' ,&coiTinandLine, 

*Q',&commandQuit, 

'S',&commandSet, 

'X',&commandExit, 

'^&commandBracket 

>; 


y**************************************** 

* 

* executeCommand(str) 

* 

* Fuehrt die Befehlsfolge aus, 

* auf die str zeigt. Das Ende 

* wird durch ein Null'Byte markiert. 

* 

* Die Funktion gibt folgendes zurueck: 

♦ 0: kein Fehler. 
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* -1: Programm beenden. 

* sonst: Zeiger auf Fehler im String. 

* bzw.: negativen Zeiger auf *>• 

* 

****************************************y 


UBYTE *executeCommand(str) 
register UBYTE ♦str; 

C 

register UBYTE *ptr,c; 
register UWORD count«n; 
register UBYTE *(*fkt)<); 

while (ImessageWaitingO && *str) 

SKlPBLANKS(Str) 

if (*str == »>') 

return (NULL - str); 

if (DIGIT(*str)) 

< 

count = 0; 

while (DIGIT(*str)) 

i 

count = 10*count + <*str - *0*); 
str-»”*-; 

> 

if (count == 0) 
count = 1; 

> 

eise 

count = 1; 

/* Suche Funktion, die Kommando ausfuehrt: V 
c = UC(*str); 
fkt = NULL; 

for (n = 0; n < sizeof(jmpTable)/sizeof 

(struct jmpEntry); 

if (c jmpTableln] .c) 
i 

fkt - jmpTableCn] .fkt; 
break; 

> 

if (fkt) 

while (imessageUaitingO && count--) 

C 

if (ptr = (♦fkt)(str 1)) 

< 

if (ptr >a 0x80000000) 
if (ptr aa -1L) 
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/* Programmefxle V 
return (ptr); 
eise 

/* Fehler aufgetreten: V 
return (NULL - ptr); 

eise 

I* Falls count == 0: Naechsten Befehl, V 
/* sonst denselben nochmals */ 
if (count == 0) 
str = ptr; 

> 

eise 

/* Abbruch */ 
return (NULL); 

> 

eise 

/* Unbekanntes Kommando V 
return (str); 

savelfCursorMoved(); 

SKIPBLANKS(str) 

if (*str == ';*) 
str++; 

eise if (*str == •>*) 
return (NULL - str); 
eise if (*str) 
return (str); 

> 

return (NULL); 

> 

Abschließend ein paar Bemerkungen zum neuen Modul: 

Da wir die Dateien über die Standard-C-Funktionen fopen, 
fclose usw. bearbeiten, müssen wir auch die Include-Datei 
stdio.h einbinden. 

Bei den Defines finden Sie nützliche Makros, um ein 
Zeichen in einen Großbuchstaben umzuwandeln (UC = 
Upper Case), um zu entscheiden, ob es sich bei einem 
Zeichen um eine Ziffer handelt (DIGIT), und um Blanks 
in einem String zu überspringen (SKIPBLANKS). 

Damit wir zur Unterscheidung der Befehle keine über¬ 
mäßig große switch-case-Anweisung brauchen, werden wir 
jeweils den Anfangsbuchstaben des Befehls und die 
Adresse der entsprechenden Funktion in einem Feld able- 
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gen. Die Datenstruktur des Feldes ist jmpEntry. Das Feld 
ist nach den Funktionen für die Befehle definiert, da die 
Funktionen bereits definiert sein müssen, wenn das Feld 
initialisiert wird (Die Adressen der Funktionen müssen 
dem C-Compiler bekannt sein!). 

Die Funktion saveASCII erwartet als Parameter einen Zei¬ 
ger auf einen Dateinamen und speichert den gesamten Text 
unter diesem Namen auf Diskette ab. Die Funktion gibt 
FALSE zurück, wenn ein Fehler aufgetreten ist. 

Gleiches gilt für die Funktion loadASCII, die aber wesent¬ 
lich komplizierter ist, da ggf. Fließtext in einzelne Zeilen 
aufgespalten werden muß. Der zu ladende Text wird dabei 
hinter der aktuellen Zeile in den bereits bestehenden Text 
eingefügt. Existiert noch kein Text, so wird der Text ganz 
normal geladen. Die Variable z zeigt dabei jeweils auf die 
vorige Zeile. 

Beim Laden werden solange einzelne Zeichen gelesen, bis ein 
Zeilenende erreicht oder die Zeile zu breit ist. Da die Funktion 
getc, die das Zeichen liest, intern mit einem Puffer arbeitet, ist 
diese Methode kaum langsamer, als wenn wir immer einen gan¬ 
zen Textblock in einen Puffer laden und daraus die Zeichen ho¬ 
len würden. Die maximale Anzahl beim Laden der Zeichen pro 
Zeile läßt sich übrigens ändern. Hier wurde die Variable rm neu 
in die Editor-Struktur eingefügt, die den rechten Rand (Right 
Margin) angibt. Der Editor Ed hat etwas Ähnliches zu bieten. 

Ist das Flag skipblanks auf Null gesetzt, so wird die Zeile am 
Anfang des letzten Wortes auf gesplittet, es wird also ein soge¬ 
nanntes Wordwrap durchgeführt. Die Funktion getLastWord, die 
wir dabei benutzen, wird noch im Modul Edit implementiert 
werden. Zurück liefert sie einen Zeiger auf den Anfang des 
letzten Wortes einer Zeichenkette. 

Ein Fehler, den das Programm bisher hatte, ist uns erst beim 
Arbeiten mit dem Editor aufgefallen. Sie erinnern sich sicher an 
die Funktion garbageColIection aus dem Modul Speicher, die 
einen Speicherblock reorganisiert. Dabei können allerdings Zei¬ 
len verschoben werden, so daß diese Funktion die Variable ak¬ 
tuell und das zeilenptr-Feld dahingehend überprüft und ggf. 
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einen Zeiger umbiegt. Nun wird aber von der Funktion 
loadASCII stets ein Zeiger auf die letzte Zeile mitgeführt, der 
auch überprüft werden müßte. Damit dies geschehen kann, 
wurde in der Editor-Struktur die Variable lineptr geschaffen, 
die von der Funktion garbageCollection überprüft wird. Haben 
wir eine lokale Variable, die auf eine Zeile zeigt, so speichern 
wir diese in lineptr ab, bevor wir die Funktion neueZeile auf- 
rufen, die ihrerseits die Funktion garbageCollection auf ruft. 
Nach dem Aufruf holen wir den Zeiger wieder aus lineptr und 
können sicher sein, daß dieser Zeiger noch auf dieselbe Zeile 
zeigt. Der erwähnte Fehler tritt in der Funktion saveLine auf, in 
der ebenfalls die Funktion neueZeile aufgerufen wird, während 
eine lokale Variable einen Zeiger auf eine Zeile enthält. Wir 
werden dies aber noch korrigieren. 

Nachdem alle Zeilen geladen sind, werden mit initFolding die 
Falten-Level aller Zeilen neu berechnet, und anschließend wird 
der Fensterinhalt neu ausgegeben. 

Die Funktionen, die die einzelnen Befehle ausführen, 
heißen commandXYZ, wobei XYZ für die Befehlsgruppe 
steht. An diese Funktionen wird ein Zeiger auf den zwei¬ 
ten Buchstaben des Befehls übergeben. Zurückgegeben 
wird wieder ein Zeiger, der normalerweise hinter den Be¬ 
fehl zeigt, aber es gibt auch Sonderfälle: Liefert die Funk¬ 
tion Null zurück, so gilt dies als Abbruchkriterium für den 
Kommando-Interpreter. Eine -1 dagegen beendet den 
Editor, was bei den Befehlen X und Q Verwendung findet. 
Erhalten Sie aber einen negativen Wert zurück, so ist ein 
Fehler aufgetreten. Sie erhalten einen Zeiger auf den Feh¬ 
ler, wenn Sie den Rückgabewert mit -1 multiplizieren bzw. 
ihn von Null abziehen. 

Die bereits implementierten Befehle bestehen im wesent¬ 
lichen aus dem Aufruf einer entsprechenden Funktion, die 
wir bereits in anderen Modulen stehen haben. Lediglich 
die ASCII-Befehle sind etwas umfangreicher, da dort ggf. 
eine Zeichenkette eingelesen werden muß. Bei den Set- 
Befehlen, die das Setzen der Flags bewerkstelligen, finden 
Sie auch den Befehl sr»nn, mit dem Sie den rechten Rand 
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für Wordwrap einstellen können. Dabei darf der Wert nn 
zwischen 10 und MAXBREITE liegen. 

Wenn Befehle geklammert werden, so wird die Funktion 
commandBracket aufgerufen, die ihrerseits die Funktion 
executeCommand aufruft (rekursiv). Die Funktion execu- 
teCommand springt zurück, wenn ein Fehler auf getreten 
oder eine geschweifte Klammer-Zu gefunden wurde. Im 
zweiten Fall wird dann die Ausführung hinter dem "}" 
fortgesetzt. Schwierig wird es, wenn die geklammerten 
Befehle abgebrochen wurden. In diesem Fall soll die 
Kommandoausführung hinter der fortgeführt werden. 
Die Funktion commandBracket sucht in diesem Fall dann 
nach dem und gibt einen Zeiger auf das darauf fol¬ 
gende Zeichen zurück. Es gibt hier übrigens keine Pro¬ 
bleme, wenn der Benutzer die Kommandofolge durch Ta¬ 
stendruck unterbrochen hatte, da dieses Abbruchkriterium 
ja bestehenbleibt. 

Die Funktion messageWaiting übernimmt die Abfrage, ob 
der Benutzer die Kommandofolge abbrechen will. Dies ist 
dann gegeben, wenn er entweder eine Taste gedrückt 
(vorzugsweise Shift-, Ctrl- oder Alt-Taste, da diese keine 
Zeichen, sondern nur RAWKEY senden!) oder die Größe 
des Fensters geändert hat. Im zweiten Fall würde die Aus¬ 
gabe nämlich nicht mehr stimmen, da einige der Werte, die 
wir für die Ausgabe in der Funktion initWindowSize be¬ 
rechnet haben, sich geändert haben können. 

Die Funktion executeCommand übernimmt die Ausführung 
der einzelnen Befehle. Dazu erwartet sie als einzigen Pa¬ 
rameter einen Zeiger auf eine Kommandofolge. Sie liefert 
Null zurück, ähnlich wie die command-Funktionen, wenn 
kein Fehler auf getreten ist, -1, um das Programm zu 
beenden, oder ansonsten einen Zeiger auf den Fehler. Ist 
der zurückgelieferte Zeiger jedoch negativ, so handelt es 
sich dabei um einen Zeiger auf ein ")". Wurde die Funk¬ 
tion executeCommand von der Funktion commandBracket 
aufgerufen, so handelt es sich dabei um das Ende einer 
geklammerten Kommandofolge. Wurde die Funktion dage¬ 
gen vom Hauptprogramm aus aufgerufen, so handelt es 
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sich um einen Fehler, da kein passendes in der Kom¬ 
mandofolge zu finden war. 

Da in C Zeiger als vorzeichenlose Werte behandelt werden, kön¬ 
nen wir nicht auf kleiner als Null abfragen, sondern wir müssen 
testen, ob der Zeiger größer als 0x80000000 ist, die eigentlich 
die kleinste negative Zahl ist, wenn man diesen Wert vorzei¬ 
chenbehaftet betrachten würde. 

Verbessern wir nun zunächst den Fehler im Modul Speicher. 
Dort müssen in der Funktion garbageCollection die beiden fol¬ 
genden Zeilen hinter die Stelle eingefügt werden, an der der 
Zeiger aktuellerEditor->aktuell überprüft wird: 

if (aktueUerEditor->lineptr == z) 
aktueUerEditor->l1neptr = fz; 

Nun zu unserer Include-Datei Editor.h, in der folgende Include- 
Dateien zusätzlich eingebunden werden müssen: 

lUinclude <stdio.h> 

#include <intuition/intuitionbase.h> 

Ferner müssen die Positionen der einzelnen Werte der Infozeile 
und deren Längen als Defines definiert werden: 

#def1ne INFO XPOS INC 2 
UWefine INF0 IxP 0S“LEN 4 
#define INF0_YP0S_INC 9 
«klefine INFO YPOS LEN 4 
#define INFO ANZZEILEN INC 16 
#define INFO~ANZZEILEN~LEN 4 
«define INFO~MINFOLO INC 22 
#define INFO MINFOLO'lEN 2 
HUefine INFO~NAXFOLD~INC 25 
#define INF0_NAXF0LD LEN 2 
#defihe INFO_FLAGS_INC 29 
#define INFoIfLAGS~LEN 5 

Die "_INC"-Defines geben an, um wie viele Zeichen der ent¬ 
sprechende Wert vom Anfang der Infozeile entfernt ist, und die 
''_LEN"-Defines geben die Anzahl der Zeichen an, aus denen 
der Wert besteht. Die Editor-Struktur wird noch um einige Ele¬ 
mente erweitert: 
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UBYTE gc_SIBuffer[256]; 
struct Stringlnfo gc_GadgetSI; 
struct Gadget G_Coiiinand; 

UBYTE gi_Text[36]; 
struct IntuiText gi_IText; 
struct Gadget G_Info; 

ULONG ip_xpos; 

ULONG ip.ypos; 

ULONG ip_anzzeilen; 

ULONG i’p~minfold; 

ULONG ip maxfold; 

ULONG ip'flags; 

ULONG ip topedge; 

UBYTE filenamelBO]; 

UWORD rm; 

struct Zeile *lineptr; 

>; 

Die ersten sechs Elemente enthalten die Strukturen der Gadgets 
für die Kommando- und die Infozeile. Dann folgen die Positio¬ 
nen der einzelnen Werte der Infozeile, der aktuelle Dateiname, 
der von der Funktion loadASCII initialisiert wird, der rechte 
Rand (Right Margin) und der Hilfszeiger auf eine Zeile, der von 
der Funktion garbageCollection berücksichtigt wird. 

Wenden wir uns nun dem Hauptmodul Editor.c zu, in das 
zunächst eine weitere Include-Datei eingebunden werden muß: 

#include <intuition/intuitionbase.h> 

Dann folgen zwei neue Defines, die den Text definieren, den 
der Editor ausgibt, wenn er vom CLI aus mit "Editor ?" aufge¬ 
rufen wird: 

«define UT1 "USAGE: Editor [Flags] <Filenaine>" 

Sdefine UT2 "Flags; [-a] [-A] [-b] t-B] [- i|l]t- o|0] t- rjRt=n]] [-t] C*T]" 

Da wir das Laden von Text eingebaut haben, wollen wir den 
Editor natürlich auch vom CLI aus starten, so daß er direkt den 
Text lädt. Ferner lassen sich dabei auch die Flags beeinflussen. 
Statt sa, wie man in der Kommandozeile des Editors eingeben 
würde, kann man beim Aufruf des Editors vom CLI alle Flags 
setzen, indem man statt des s ein - vor das Flag setzt, also z.B.: 
-a. Doch dazu später. Nun erstmal die zusätzlichen externen 
Funktionen: 
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void strncpy()fCloseFont(),puts(); 

void printXposC),printYpos(),printInfo(),DisplayBeep(); 
struct Text Font ♦OpenFontO; 

BOOL handleKeys(),ActivateGad 9 et(),loadASCIK); 

UBYTE *executeCommandC), *coinmandSet ( ); 

Beachten Sie bitte, daß die Funktion handleKeys jetzt vom Typ 
BOOL ist. Den Grund dafür werden Sie erkennen, wenn wir das 
Modul Cursor geändert haben. Bei den globalen Variablen defi¬ 
nieren wir nun die beiden Gagdets, die im unteren Fensterrah¬ 
men die Funktion von Kommado- und Infozeile übernehmen. 
Die Kommandozeile wird dabei durch das String-Gadget 
G_Command repräsentiert, während für die Infozeile das Boo- 
lean-Gadget G_Info zuständig ist 

UBYTE gc SIBufferC256]; 

UBYTE gcIUndoBuffer[256]; 
struct Stringlnfo gc CadgetSI - 
t 

gc_SlBuffer, 

gc~UndoBuffer, 

0 ." 

256, 

0 . 

o.o.o.o.o, 

0 . 

NULL, 

NULL 

>; 


SHORT gc_BorderVectorst4] = {0,0,350,0>; 
struct Border gc Border * 


- 1 .- 1 . 

1,0,JAN1, 

2 . 

gc BorderVectors, 
NULL 


>; 


struct Gadget G Conmand » 
i 

NULL, 

2 .- 9 . 

-302,9, 

GADGHCOMP j GRELBOTTOH | GRELUIDTH, 
RELVERIFY j BOTTOMBORDER, 

STRGADGET, 

(APTR)&gc Border, 

NULL, 

NULL, 
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0 , 

(APTR)&gc_GadgetSI, 

2 . 

NULL 


SHORT gi_BorclerVectorsCl4] = 

<-1,0,-1,10,0,10,0,0,298,0,298,1,283,1>; 
struct Border gi Border = 
i 

0 , 0 , 

1,0,JAM1, 

7, 

gi_BorderVectors, 

NULL 


struct TextAttr TOPAZ80 = 
i 

(STRPTR)«topa 2 .font«, 
TOPAZ EIGHTY,0,0 


UBYTE gi\.Text[36] = «X= 1 Y= 1 #= 0 [ 0, 0] IcATB»; 

struct IntuiText gi IText = 
i 

1,0,JAM2, 

4 , 2 , 

&TOPAZ80, 
gi Text, 

NULL 


struct Gadget G Info » 
i 

&G_Coiiinand, 

-298,-10, 

280,10, 

GADGHNONE j GRELBOTTOM | GRELRIGHT, 
RELVERIFY | BOTTOMBORDER, 
BOOLGAOGET, 

(APTR)&gi_Border, 

NULL, 

&gi IText, 

0 , " 

NULL, 

Ir 

NULL 


struct NewWindow newEdUindou » 
0,0,640,200, 

AUTOFRONTPEN,AUTOBACKPEN, 
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REFRESHWINDOW | MOUSEBUTTONS \ RAWICEY | CLOSEWINDOW | 

NEWSIZE I GADGETUP, 

WINDOWSIZING I WINDOWDRAG j WINOOWDEPTH j 

WINDOWCLOSE | SIZEBBOTTOM 

I SINPLE_REFRESH | ACTIVATE, 

NULL.NULL, 

NULL, 

NULL,NULL, 

320,50,640,200, 

WBENCHSCREEN 

>; 

struct TextFont *infoFont = NULL; 

Das Fenster erlaubt nun auch GADGETUP-Events, damit das 
Programm eine Nachricht erhält, wenn im String-Gadget die 
Return-Taste gedrückt wurde und damit eine Kommandofolge 
zur Ausführung gebracht werden soll. Da wir später mehrere 
Editorfenster öffnen können wollen, müssen wir Teile dieser 
Gagdets in die Editor-Struktur kopieren, da keine zwei Fenster 
dieselben Gadgets benutzen können. Allerdings brauchen wir 
nicht alle Strukturen zu kopieren. So reicht beispielsweise eine 
Border-Struktur für alle Fenster, da diese vom Betriebssystem 
nicht verändert, sondern nur ausgelesen wird. Benötigt werden 
aber der Puffer für die Kommandozeile SIBuffer, damit wir in 
zwei Fenstern auch zwei verschiedene Kommandofolgen einge¬ 
ben können, die Stringlnfo-Struktur, der Text der Infozeile, die 
IntuiText-Struktur, die auf diesen zeigt, und natürlich die bei¬ 
den Gadget-Strukturen. 

Die Gadgets und die anderen Strukturen werden in der Funktion 
OpenEditor in die Editor-Struktur kopiert. Dies geschieht direkt 
nach Beschaffung des Speichers für die Editor-Struktur, da die 
Gadgets ja noch in die NewWindow-Struktur eingebunden wer¬ 
den müssen, damit diese auch im Fenster erscheinen. Auch darf 
nicht vergessen werden, die Zeiger der Strukturen aufeinander 
zu setzen, da diese nach dem Kopieren in die Editor-Struktur 
nicht mehr stimmen. Im folgenden nochmals die Funktion Open¬ 
Editor, wobei die Initialisierung der restlichen Parameter aus¬ 
gespart wurde, da diese gleich geblieben ist: 

struct Editor *OpenEditor() 

register struct Editor *ed = NULL; 
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reg 1 Ster struct Window *wd; 
register struct RastPort *rp; 
ULONG flags; 


/* IDCMPFlags retten, in Struktur auf NULL setzen! 

=> eigenen UserPort verwenden! V 
flags s newEdWindow.lDCHPFlags; 
newEdWindow.IDCMPFlags = NULL; 


/* Speicher fuer Editor-Struktur beschaffen: V 
if (ed = malloc(sizeof(struct Editor))) 


/* Gadgets initialisieren: V 


ed->gc_SIBuffer[0] 
ed->gc_GadgetSI 
ed->G_Coinmand 
ed->gi_IText 
ed->G Tnfo 


0 ; 

gc_GadgetSI; 
G_Coninand; 
gi^IText; 
G_Tnfo; 


strncpy(ed->gi_Text,gi_Text,sizeof(ed->gi_Text)); 


/* Zeiger setzen: */ 
ed->gc_GadgetSI-Buffer 
ed->G_Command.SpecialInfo 
ed->gi_IText.IText 
ed->G_Tnf 0 .NextGadget 
ed- >G_Inf 0 .GadgetText 
newEdWindow.FirstGadget 
newEdWindow.Title 
ed->filenamelO] 


= ed->gc SIBuffer; 

= (APTR)“&(ed->gc_GadgetSI); 
= ed->gi_Text; 

= &(ed->G_Coiiinand); 

= &(ed->gi_IText); 
s &(ed->G_Tnfo); 
s ed->filenaine; 

= 0; 


/* Fenster oeffnen: V 

if (wd - OpenWindow(&newEdWindow)) 

i 

ed->window = wd; 

ed->rp = (rp = wd->RPort); 


y******************************************** 

* * 

* Wie gehabt die Parameter initialisieren! * 

* * 

* (Von den Schreibmodi bis maxfold !!!!!!) * 

* * 

********************************************y 


ed->rm - MAXBREITE; 

i 

register UBYTE *ptr; 
register struct Zeile ♦♦zptr; 
register UWORD n,*pnr; 

/* zeilenptr/nr-Array initialisieren: V 
for (n = 0, zptr = ed->zeilenptr, pnr = ed->zeilennr; 
n < MAXHOEHE; n++, zptr++, pnr-*-*»-) 






716 


Das große C-Buch zum Amiga 
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*zptr = NULL; 

*pnr =1; 

> 

/* Tabulatoren initialisieren: V 
ptr = ed->tabstring; 

*ptr+*»- = 1; 

for (n = 1; n < MAXBREITE; n++) 
if (n % 3) 

*ptr++ = 1; 
eise 

*ptr++ = 0; 

> 

i 

regiSter struct Editor *olciae; 

ed->wch = 0; 
initWindowSize(ed); 

oldae = aktuellerEditor; 

aktuellerEditor = ed; 
printlnfoO; 

aktuellerEditor » oldae; 

> 

> 

eise 

free(ed); 
ed = NULL; 

> 

> 

newEdUindow.IDCMPFlags = flags; 
return (ed); 

> 

Am Ende von OpenEditor wird die Infozeile nochmals ausgege¬ 
ben, damit diese auch mit den tatsächlichen Werten überein¬ 
stimmt. Dazu muß die Variable aktuellerEditor auf den neu ge¬ 
öffneten Editor umgebogen werden, da die Ausgabefunktionen 
für die Infozeile voraussetzen, daß aktuellerEditor auch wirklich 
auf den aktuellen Editor zeigt. 

Unser Hauptprogramm muß ebenfalls in größerem Umfang ge¬ 
ändert werden. Die Funktion main erwartet nun die beiden Pa¬ 
rameter arge und argv, die alle Parameter beinhalten, die dem 
Programm vom CLI aus mitgegeben wurden. Ganz zu Anfang 
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des Programms, noch bevor die Librarys geöffnet werden, wird 
nun getestet, ob der Editor mit "Editor ?" auf gerufen wurde. In 
diesem Fall wird nur die Syntax des Aufrufs ausgegeben und 
danach das Programm beendet. Zur Ausgabe verwenden wir die 
Funktion puts, die einen String ausgibt, aber nicht so umfang¬ 
reich wie die Funktion printf ist. 

Nach dem öffnen der Librarys wird auch der Zeichensatz für 
die Infozeile geöffnet und ein Zeiger darauf in der Variablen 
infoFont abgelegt. Bevor der Editor geöffnet wird, stellt das 
Programm die maximale Höhe des Bildschirms fest und trägt sie 
in die NewWindow-Struktur ein, so daß das Fenster beim öff¬ 
nen die maximale Größe besitzt. Als Zeiger auf den Bildschirm 
wird die Variable ActiveScreen der IntuitionBase-Struktur ver¬ 
wendet, die auf den gerade aktiven Bildschirm zeigt. 

Nachdem das Editorfenster geöffnet ist, wird die Kom#mando- 
zeile ausgewertet, die dem Programm vom CLI aus mitgegeben 
wurde. Dabei wird vorausgesetzt, daß der Dateiname zu allerletzt 
angegeben wird. Sonst, und auch im Falle anderer Fehler, wird 
das Programm beendet, nachdem die Syntax des Programmauf¬ 
rufes ausgegeben wurde. Der einzige Fehler, der das Programm 
nicht stört, ist, wenn die Datei nicht gefunden wurde, die der 
Editor laden soll. 

Die Hauptschleife ist im wesentlichen gleich geblieben, die 
Funktion handleKeys gibt nun aber einen Wert vom Typ BOOL 
zurück. Ist dieser FALSE, so wird das Programm abgebrochen. 
In den Programmstücken für MOUSEBUTTON und NEWSIZE- 
Messages wird nun. die Cursor-Position mit printXpos und 
printYpos ausgegeben, falls diese verändert wurde. 

Neu ist die Abfrage für GADGETUP-Messages, über die die 
Ausführung der Kommandozeile gestartet wird. Tritt dabei ein 
Fehler auf, so wird der Cursor des Gadgets auf die fehlerhafte 
Stelle gesetzt und das String-Gadget aktiviert. Da in der GAD- 
GETUP-Abfrage nicht überprüft wird, welches Gadget diese 
Message verursacht hat, können Sie die Kommandozeile ausfüh¬ 
ren lassen, indem Sie mit der Maus auf die Infozeile klicken. 
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Dies sorgt dafür, eine bereits eingegebene Kommandofolge 
nochmals ausführen zu lassen. 

Geändert wurde auch der Schluß des Programms. Hier werden 
alle Variablen, die getestet werden, explizit auf Null gesetzt. Der 
Grund dafür liegt in einem Hilfsprogramm namens SHELL. Da¬ 
bei handelt es sich um ein verbessertes CLI, das es erlaubt. Be¬ 
fehle als resident zu definieren. Dies bedeutet, daß der entspre¬ 
chende Befehl geladen und im Speicher behalten wird, unabhän¬ 
gig davon, wie oft er ausgeführt wird. Der Vorteil ist einmal, 
daß der Befehl nicht erst geladen werden muß und daß weniger 
Speicherplatz vergeudet wird, als wenn der Befehl auf die 
RAM-Disk kopiert werden würde. Denn wenn der Befehl auf 
die RAM-Disk kopiert wird, so muß er trotzdem noch geladen 
werden, bevor er ausgeführt werden kann. Ist er dagegen als re¬ 
sident definiert, so befindet er sich nur einmal im Speicher und 
wird bei Aufruf einfach nur aktiviert. 

Allerdings müssen Befehle bzw. Programme, die als resident de¬ 
finiert werden sollen, bestimmte Forderungen erfüllen. So dür¬ 
fen Sie nicht voraussetzen, daß Variablen initialisiert sind, da 
deren Inhalt ja noch von einem früheren Aufruf stammen kann. 
Um dies zu umgehen, setzen wir alle wichtigen Variablen am 
Ende des Programms wieder auf ihren Anfangswert. Dadurch 
erreichen wir, daß der Editor jedesmal initialisierte Anfangs¬ 
werte vorfindet. Doch nun zu unserem neuen Hauptprogramm; 


main(argc,argv) 
int arge; 

UBYTE *argv[]; 
i 

regiSter struct Editor ♦ed; 

BOOL running = TRUE; 

register struct IntuiMessage *imsg; 

ULONG signal,class,mouseX,inouseY; 

UUORD code^qualifier; 

APTR iaddress; 

/* Falls Editor mit "Editor ?•* aufgerufen wurde, 

nur Text ausgeben V 

if (arge == 2) 

if (♦argv[1] « *?*) 
i 


puts(UTI); 

puts(UT2); 
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goto Ende; 

> 

/* Librarys oeffnen: */ 

if ( !(IntuitionBase = OpenLibrary(”intuition.library”,REV))) 
goto Ende; 

if ( KGfxBase = OpenLibrary("graphics.library*',REV))) 
goto Ende; 

if ( KDosBase » OpenLibraryC'dos.Library'*,REV))) 
goto Ende; 

if ( !(OpenDevice("console.device",’lL,&ioStdReq,OL))) 
ConsoleDevice = ioStdReq.io_Device; 
eise 

goto Ende; 

/* Font fuer Infozeile oeffnen: V 

if (! (infoFont = OpenFont(&T0PAZ80))) goto Ende; 

/* UserPort oeffnen V 

if (! (edUserPort = CreatePort(NULL,OL))) goto Ende; 

t* Maximale Größe für Fenster bestimmen: V 
newEdWindow.Height - newEdUindow.MaxHeight = 

((struct IntuitionBase *)IntuitionBase)-> 

ActiveScreen->Height; 

/* Editor-Liste initialisieren: V 
NewList(&editorlist); 

/* Erstes Editorfenster oeffnen: V 
if (ed = OpenEditorO) 

< 

AddTail(&editorList,ed); 
aktuellerEditor = ed; 

> 

eise 

goto Ende; 

t* Kommandozeile bearbeiten: V 
if (arge >= 2) 

C 

register UUORD n > 1; 

while (n < arge) 

if (*argv[n] == 

C 

if (eoiiiiiandSet(argv[n] *»* 1) >» 0x80000000) 

DisplayBeep(NULL); 
break; 

> 

> 

eise 
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if (loadASCII(argv[n])) 
printAUO; 
eise 

DisplayBeep(NULL); 

/* Dateiname nur am Ende erlaubt! */ 

n++; 

break; 

> 

n++; 

> 

if (n < arge) 
i 

/* Fehler! V 
puts(UTl); 
puts(UT2); 
goto Ende; 

> 

> 


/* Cursor setzen: */ 

Cursore); 

Signal = UaitClL « edUserPort->mp_SigBit); 

/* Cursor wieder loeschen: */ 

Cursore); 

while eimsg s GetMsgeedUserPort)) 

< 

dass s imsg->Class; 

Code s im8g’>Code; 

qualifier s imsg->Qualifier; 
iaddress » imsg'>lAddress; 

mouseX s imsg‘>MouseX; 

mouseY s imsg->MouseY; 

ReplyHsgeimsg); 

/* Event bearbeiten: V 
switch edass) 
i 

case RAUKEY: 
i 

register struct IntuiMessage *im1,*im2; 

if e! ecode & lECODE UP PREFIX)) 

€ 

inputEvent.ie_Code * code; 
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inputEvent.ie^Qualifier = qualifier; 
if ((inputLen = RawKeyConvert( 

&inputEvent,inputPuf fer,MAXINPUTLEN,NULL) 
) >= 0 ) 

running = handleXeysCinputPuffer,inputLen); 


/* Nach laufen verhindern: V 
iml B (struct IntuiMessage *) 

edUserPor t - >inp_MsgL i st. l h_Head; 
while (im2 = (struct IntuiMessage *) 

im1’>ExecMessage.mn Node.ln_Succ) 

< 

if (im2’>ExecMessage.mn_Node.ln_Succ == NULL) 

break; 

if (im1->Class I- RAWKEY) break; 
if (!(im1->Qualifier & lEQUALIFIER.REPEAT)) 

break; 

if <im2->Class != RAWKEY) break; 
if (!<iin2>>Qualifier & lEQUALIFIER^REPEAT)) 

break; 

/* Message entfernen: */ 
im1 s GetMsg(edUserPort); 

ReplyMsg(iml); 

iml = (struct IntuiMessage *) 

edUserPort->inp MsgList.lh Head; 

> 

break; 

> 

case MOUSEBUTTONS: 
i 

regiSter WORD x,y; 

if (mouseX <= aktuellerEditor->xoff) 

X s 0; 
eise 

X = (mouseX - aktuellerEditor->xoff) 

/ aktuellerEditor->cw; 
if (++X >= aktuellerEditor->wcw) 

X = aktuellerEditor->wcw - 1; 

X += aktuellerEditor->leftpo8; 
if (X > MAXBREITE) 

X r MAXBREITE; 

if (mouseY <* aktuellerEditor->yoff) 

y = 0 ; 

eise 

y = (mouseY - aktuellerEditor->yoff) 

/ aktuellerEditor->ch; 


if (Cy < aktuetlerEditor->wch) 
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&& (aktueUerEditor->zei lenptrCy])) 

C 

aktuellerEditor>>xpos = x; 
aktuellerEditor->udy = y; 
aktueUerEditor->ypos = 

aktuellerEditor->zeilennrCy]; 

printXposO; 

printYposO; 

> 

> 

case NEUSIZE: 

inituindowSize(aktuellerEditor); 

/* Pruefe, ob Cursor noch im Fenster! V 
if (aktuellerEditor->xpos > 

aktuellerEditor->leftpos 
■»-aktuel lerEdi tor->wcw) 
i 

aktuellerEditor->xpos = aktuellerEditor*>leftpos 
aktuellerEditor->wcw; 

printXposO; 

> 

if (aktuellerEditor‘>wdy >= aktuellerEditor->wch) 
i 

aktuellerEditor->ypos = 

aktuellerEditor->zeilennr 
[(aktuellerEditor->wdy= 

aktuellerEditor->wch - 1)]; 

printYposO; 

> 

break; 

case REFRESHUINOOU: 

BeginRefresh(aktuellerEditor'>window); 

printAlK); 

EndRefresh(aktuellerEditor->window,TRUE); 
break; 

case GADGETUP: 

C 

register UBYTE *ptr; 
regiSter SHORT pos,hw; 

if (ptr s executeCommand 

(aktuellerEditor->gc_SIBuffer)) 
if (ptr == -1L) 
running = FALSE; 
eise 
i 


if (ptr >® 0x80000000) 
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ptr = NULL - ptr; 

/* Cursor in StringGadget auf Fehler setzen V 
pos = ptr - aktueUerEditor->gc_SlBuffer; 
aktueUerEditor*>gc_GadgetSI .BufferPos = pos; 
if (pos < aktueUerEditor-> 

gc_GadgetSI.DispCount) 
aktuellerEd{tor‘>gc_GadgetSI.DispPos ^ 0; 
eise 

aktuellerEditor->gc_GadgetSI .DispPos - pos 
- aktuellerEditor-> 

gc_GadgetSI.DiSpCount / 2; 

/* Gagdet aktivieren: V 

Act i va t eGadget (&( aktue 11 erEdi tor - >G_Coinmand), 
aktuellerEditor*>window,NULL); 
DisplayBeep< NULL); 

> 

break; 

> 

case CLOSEWINDOW: 
running = FALSE; 
break; 

default: 

printf<**Nicht bearbeitbarer Event: Xlx\n'*,class); 

> /* of case */ 

savelfCursorHovedC); 

> /* of while (GetMsgO) V 

> while (running); 

Ende: 

/* Alle Editorfenster wieder schliessen: V 
while (ed - RefnHead(&editorList)) 

CloseEditor(ed); 

/♦ UserPort schliessen: V 
if (edUserPort) 

< 

DeletePort(edUserPort); 
edUserPort = NULL; 

> 

!* Font schliessen: V 
if (infoFont) 

C 

CloseFont(infoFont); 
infoFont = NULL; 

> 
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/* Librarys schliessen: V 
if (DosBase) 

< 

CloseLibrary(DosBase); 

DosBase = NULL; 

> 

if (GfxBase) 

< 

CloseLibrary(GfxBase); 

GfxBase = NULL; 

> 

if (IntuitionBase) 

< 

CloseLibrary(IntuitionBase); 

IntuitionBase > NULL; 

> 

> 

Zum Auswerten der CLI-Kommandozeile wird die Funktion 
commandSet verwendet, so daß Sie die Flags genauso setzen 
können wie in der Kommandozeile des Editors, nur daß Sie die 
einzelnen Befehle durch ein Blank statt des Semikolons trennen 
und ein - als ersten Buchstaben setzen (statt des s). Ein mög¬ 
licher Aufruf des Editors wäre: 

Editor -r=60 -b -t Fliesstext.ASC 

Hiermit könnte man dann Fließtext editieren, wobei die Text¬ 
breite auf 60 Zeichen gesetzt wird. Das Ganze würde zwar nicht 
genauso einfach funktionieren wie bei einer Textverarbeitung, 
da uns die Befehle fehlen, um einen Absatz neu zu formatieren, 
aber immerhin. 

Auch im Modul Cursor sind einige Änderungen vorzunehmen. 
Beginnen wir mit einigen neuen Defines: 

#def1ne CEND 'S' 

«define ESC 27 
#clefine TAB 9 
#define REPCOM 7 

Da wir jetzt das Umschalten der Flags über die Kommandozeile 
vornehmen werden, können wir auf das Umschalten über Con¬ 
trol-Codes verzichten, so daß Sie die Defines TABMODE, 
WRITEMODE und AUTOINDENT löschen können. 
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Neu sind auch die folgenden externen Funktionen, die wir für 
die Info- und die Kommandozeile brauchen: 


void printXpos(),printYpos(),printFold(},printFlagst); 

BOOL ActivateGadgetO; 

UBYTE *executeConniandO; 

Im folgenden müssen an allen Stellen, an denen die Cursor-Po¬ 
sition oder andere Werte der Infozeile geändert werden (cursor- 
Left, cursorRight, cursorUp, cursorDown, halfPageUp, halfPa- 
geDown, cursorHome, enterFold, exitFold), die Aufrufe der 
entsprechenden Funktionen (printXpos, printYpos, printFold) 
eingebaut werden. Hinzu kommen drei neue Funktionen zur 
Cursorbewegung, die den Cursor auf das Ende einer Zeile, an 
den Textanfang oder an das Textende setzen: 


y*************************************** 

* 


* cursorEnd: 

★ 


* Setzt den Cursor auf das Zeilenende. 

* 

*************************************** j 


BCX)L cursorEndO 
C 

register UBYTE *ptr,*tab; 
regiSter UUORD len,pos; 
register struct Zeile *z; 

if (aktuellerEditor->pufypos) 

pos = aktuel lerEditor->puf len 1; 
eise 

if (z = ZEILENPTR(aktuellerEditor->wdy)) 
C 

/♦ Zuerst von-Laenge CR abziehen: */ 
len = z->len; 

ptr = ((UBYTE *)(z 1)) len - 1; 

if (len) 

if (*ptr == CR) 
len--; 

eise if (*ptr == LF) 
if (--len) 

if (*--ptr == CR) 
len--; 

if (aktuellerEditor->tabs) 

ptr = ((UBYTE *)(z 1)); 

tab = aktuellerEditor->tabstring; 
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pos = 1; 

white (den--) && (pos < MAXBREITE)) 
if (*ptr++ == TAB) 
do 

tab++; 

pos++; 

> while ((*tab) && (pos < MAXBREITE)); 
else 

tab<-^; 

POS++; 

> 

> 

eise 

pos = len 1; 

> 

eise 

return (FALSE); 
aktuellerEditor->xpos = pos; 

if (pos >= (aktuellerEditor'>leftpos + aktuellerEditor->wcw)) 
scrollieft(pos ♦ 1 - (aktuellerEditor->leftpos 
♦ aktuellerEditor->wcw)); 
eise if (pos <= aktuellerEditor->leftpos) 

scrollRight(aktuellerEditor'>leftpos ♦ 1 - pos); 

printXposO; 

return (TRUE); 


* 

* cursorTop: 

* 

Setzt Cursor auf Text- bzw 

* Faltenanfang. 

* 

***************************** ^ 

BOOL cursorTopO 
C 

register struct Zeile ♦z; 
UUORD n; 

register UUORD ent; 

z = ZEILENPTR(O); 
n = ZEILENNR(O); 
ent * 0; 

while (z s prevLine(z,&n)) 
cnt++; 
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if (ent) 

scrollDown(cnt); 

aktueUerEditor->ypos » ZEILENNR(aktuellerEditor’>wdy = 0); 
printYposO; 

return (TRUE); 


^****4r************************ 

* 

* cursorBottom: 

* 

* Setzt Cursor auf Text- bzu 

* Faltenende. 


***************************** ^ 


BOOL cursorBottomO 
C 

register struct Zeile *z; 

UWORD n; 

register UWORD weh,ent; 

if (z = ZEILENPTR(ueh * aktuellerEditor->weh - 1)) 
i 

n - ZElLENNR(ueh); 
ent = 0; 

while (z = nextLine(z,&n}) 
ent++; 


if (ent) 

serollUp(ent); 

aktuellerEditor’>ypos = 

ZEILENNR(aktuellerEditor->wdy s weh); 

> 

eise 

i 

aktuellerEditor->ypo8 = 

ZEILENNR(aktuellerEditor->wdy » weh); 
eursorOnTextO; 

> 

printYposO; 
return (TRUE); 

> 

Dabei ist cursorEnd noch die komplizierteste Funktion, da das 
Ende der Zeile über die Tabulatoren berechnet werden muß. Die 
Funktion cursorTop zählt die Zeilen, die noch oberhalb des 
Fensters liegen, und scrollt um diesen Wert nach unten. Die 
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Funktion cursorBottom arbeitet genauso, nur daß hier der Fall 
abgefangen werden muß, daß bereits in der untersten Zeile des 
Fensters kein Text mehr sichtbar ist. Sie können diese drei 
Funktionen nach der Funktion cursorHome einfügen. 

Die Funktion handleKeys definieren Sie nun so, daß diese einen 
Rückgabe wert vom Typ BOOL liefert: 

BOOL handteKeystbuf,len) 

In der zweiten Switch-Case-Anweisung, in der die Abfrage für 
alle CSI-Sequenzen stattfindet, die mit CSI ’ ’ beginnen, fügen 
Sie hinter der Abfrage für CURSORHOME drei Zeilen ein: 

case CEND: 
cursorEndO; 
break; 

In der zweiten großen Switch-Case-Anweisung, in der die Ab¬ 
fragen auf Control-Codes stehen, fügen Sie am Anfang, also vor 
der Abfrage für CFOLD, die folgenden Zeilen ein: 


case ESC: 

/* Rest von buf uebertragen: V 
C 

reg 1 Ster UBYTE *sibuf; 
regiSter UUORD ent; 

sibuf = aktuellerEditor->gc_SIBuffer; 
while (len) 
i 

’^sibuf++ = *buf++; 
len--; 

> 

♦sibuf = 0; 

ent = (sibuf - aktuellerEditor->gc_SIBuffer); 
aktuellerEditor->gc_GadgetSI.BufferPos = ent; 
aktuellerEditor->gc_GadgetSl.NumChars = ent; 
aktuellerEditor->gc GadgetSI.DispPos - 0; 

> 

/♦ Gagdet aktivieren: */ 

i f (I Act i vateGadget (&( aktuell erEdi tor- >G_Coiiiiiand), 
aktue 11 erEdi tor- >wi ndou, MULL)) 
DisplayBeep(NULL); 
break; 

case REPCOM: 
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c 

reg1 Ster UBYTE *ptr; 
reg1 Ster SHORT pos^hw; 

if (ptr = executeConinand(aktueUerEditor’>gc_SIBuffer)) 
if (ptr == -1L) 
return (FALSE); 
eise 
C 

if (ptr >= 0x80000000) 
ptr = NULL - ptr; 

/* Cursor in StringGadget auf Fehler setzen V 
pos = ptr - aktuellerEditor->gc_SIBuffer; 
aktuellerEditor->gc_GadgetSI-BufferPos = pos; 
if (pos < aktuellerEditor->gc_GadgetSI.DispCount) 
aktuellerEditor->gc_GadgetSI.DispPos = 0; 
else 

aktuellerEditor*>gc_GadgetSI.DispPos = pos 

- aktuellerEditor->gc_GadgetSI.DispCount / 2; 

/* Gagdet aktivieren: */ 

ActivateGadget(&(aktuellerEditor’>G_Coinnand), 
aktuellerEditor’>window,NULL); 

DisplayBeep(NULL); 

/* sofort zurueck: V 
return (TRUE); 

> 

break; 

> 

Im Falle von Escape (ESC) wird der Rest der Zeichen, die von 
der Tastatur geschickt wurden, in die Infozeile geschrieben, und 
diese wird dann aktiviert. Allerdings erhält die Übertragung des 
Restes der Zeichen erst dann Bedeutung, wenn die Tastatur frei 
belegbar ist. Dann könnten wir eine Taste so belegen, daß diese 
zuerst ein Escape und dann den Anfang einer Befehlsfolge sen¬ 
det, die wir dann nur noch mit Return starten müssen. 

Die zweite Case-Anweisung behandelt den Fall, daß man Ctrl-G 
gedrückt hat (REPCOM), was eine wiederholte Ausführung der 
Kommandozeile bedingt. Im Falle eines Fehlers wird, genau wie 
in der GADGETUP-Abfrage im Hauptprogramm, der Cursor 
der Kommandozeile auf den Fehler gesetzt und diese aktiviert. 
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Löschen müssen Sie die Abfragen auf TABMODE, WRITE- 
MODE und AUTOINDENT, da wir diese Flags nun über die 
Kommandozeile einstellen können. Dies hat den Vorteil, daß wir 
nicht mehr aus Versehen die falsche Taste drücken können und 
daß wir zusätzliche Control-Codes direkt in den Text einfügen 
können. Denn eine Besonderheit unseres Editors ist, daß wir 
Texte einiesen können, die aus beliebigen Zeichen bestehen. 

Beim Ausprobieren des Editors stellten wir fest, daß die Return- 
Taste ein CR sendet, daß aber andere Programme des CLI (wie 
TYPE) nichts mit Zeilen anfangen konnten, die durch ein CR 
abgeschlossen sind. So lange wir also die Tastatur noch nicht frei 
belegen können, werden wir immer ein LF als Zeilenende be¬ 
nutzen, damit wir die Texte, die wir mit unserem Editor ge¬ 
schrieben haben, auch von anderen Programmen lesen lassen 
können. Die Abfrage auf CR und LF sieht damit wie folgt aus: 

case LF: 
case CR: 

if (! insertLine((UBYTE) LF» 

DisplayBeeptNULL); 
break; 

Damit wären wir mit dem Modul Cursor fertig und können uns 
nun den letzten Änderungen im Modul Edit zuwenden. Dort de¬ 
klarieren wir wieder ein paar neue externe Funktionen: 

void printXpos(),printYpos(),printFold(); 
void printAnzZeilen(),printFlagst); 

BOOL cursorEndO; 

Auch in diesem Modul gilt es, an allen Stellen, an denen Werte 
der Infozeile geändert werden könnten, Aufrufe der entspre¬ 
chenden Funktionen (printXpos, printYpos, printFold, print- 
AnzZeilen und printFlags) einzubauen. 

In der Funktion saveLine muß ein lokaler Zeiger auf eine Zeile 
in die Variable lineptr der Editor-Struktur gerettet werden, be¬ 
vor die Funktion neueZeile aufgerufen wird. Das entsprechende 
Programmstück sieht danach wie folgt aus: 
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/* ggf. neue Zeile beschaffen: V 
if (EVENLEN(len) != EVENLENdeile->len)) 

< 

alctueUerEditor->lineptr = zeile; /* wg. Garbage-Collection V 
if (Zeile = neueZeile(len)) 

C 

old = aktuellerEditor->lineptr; 

Insert(&aktuellerEditor->zeilen,zeile,old); 
zeile->flags = old->flags & "ZLF^USED; 
loescheZeile<old); 

I* Nun eventuelle Zeiger unsetzen: V 
for (1=0, zptr = aktuellerEditor->zeilenptr; 
l <= aktuellerEditor*>wch; l*»*+, zptr-«”*-) 
if (*zptr == old) 

*zptr = zeile; 
break; 

> 

aktuellerEditor->lineptr = NULL; 

> 

eise 

< 

aktuellerEditor->lineptr = NULL; 
return (FALSE); 

> 

> 

eise 

C 

zeile->len = len; 
zeile->flags &= "ZLF^USED; 


Vergessen Sie bitte nicht, in diese Funktion die Aufrufe von 
printYpos und printFlags (da changed gesetzt wird) einzubauen. 
Auch in die Funktion getPufferPointer gehört ein Aufruf von 
printAnzZeilen, da ggf. eine erste Zeile neu eingerichtet wird. 
Die Funktionen deleteChar und backspaceChar ändern Sie bitte 
so ab, daß sie immer TRUE zurOckliefern. Die Unterscheidung 
zwischen TRUE und FALSE hat sich an dieser Stelle leider 
nicht bewährt. Vor allem beim Ausführen von Befehlsfolgen 
führte dies oft zum vorzeitigen Abbruch. 

In der Funktion insertLine ist eine kleine Änderung nötig, ohne 
die der Befehl LS (Line Split) nicht richtig funktioniert. Statt 
das Zeichen, das die Zeile aufgetrennt hat (in der Regel LF), 
immer in die Zeile zu schreiben und die Länge um Eins zu er- 
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höhen, werden wir dies ab jetzt nur dann machen, wenn das 
Zeichen nicht den Wert Null hat 

/* Zeile dekonvertieren: •/ 

p2 = buf + (len = deconvertLine(buf,aktuellerEditor->puffer,inc)); 
if (*p2 = c) 
len++; 

Dadurch können wir Zeilen auch aufsplitten, ohne daß ein Zei¬ 
chen eingefügt wird. Am Ende der Funktion müssen eine ganze 
Reihe von Werten der Infozeile neu ausgegeben werden; 

printXposO; 
printYposO; 
printAnzZeilen(); 
printFlagst); 

Falls minfold und maxfold geändert wurden, so muß an den 
entsprechenden Stellen auch printFold aufgerufen werden. 

Leider ist uns in der Funktion deleteLine ein kleiner Fehler un¬ 
terlaufen, den wir erst bemerkten, als wir die Infozeile imple¬ 
mentiert hatten. Sie erinnern sich, daß wir bereits einmal die Y- 
Position falsch berechnet hatten und dies nur mit dem Debugger 
feststellen konnten, da wir zu diesem Zeitpunkt noch keine In¬ 
fozeile hatten. Etwas Ähnliches ist uns in der Funktion 
deleteLine passiert, und zwar an den Stellen, an denen die Zei¬ 
ger auf die nächste und die vorige Zeile bestimmt werden: 

prevnr = ZEILENNR(aktuellerEditor->wdy); 
prev = prevLinetzeile,&prevnr); 
nextnr = ZEILENNR(aktuellerEditor->udy); 
next = nextLine(zeile,&nextnr); 

Leider haben wir dabei nicht bedacht, daß die nächste Zeile 
dieselbe Zeilennummer hat wie die aktuelle Zeile, da die aktu¬ 
elle Zeile ja gelöscht wird. Daher müssen die beiden Stellen, an 
denen die obige Befehlsgruppe auftritt, wie folgt abgewandelt 
werden: 

prevnr = ZEILENNR(aktuellerEditor->wdy); 
prev = prevLine(zeile,(prevnr); 
next s nextLine(zeile,(nextnr); 
nextnr = ZEILENNR(aktuellerEditor->wdy); 
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Daß dabei nextnr nicht initialisiert ist, wenn nextLine aufgeru¬ 
fen wird, stört nicht, da in der Funktion nextLine der Wert von 
nextnr ohnehin nur um eins erhöht wird. 

Neu hinzugekommen ist die Funktion getLastWord, die von ei¬ 
nem gegebenen String den Zeiger auf das letzte Wort zurücklie¬ 
fert. Diese Funktion fügen Sie bitte vor der Funktion insertChar 
ein: 


* 

* getLastWord(str,len) 

* 

* Gibt Zeiger auf den Anfang des 

* letzten Wortes des Strings zurueck. 

* Dabei wird vorzugsweise nach einem 

* Wort gesucht, vor dem ein Leer- 

* Zeichen steht. 

* 

* str * String. 

* len = dessen Laenge. 

* 


****************************4r*********^ 


UBYTE ♦getLastWordCstr,len) 
register UBYTE *str; 
register UWORD len; 

i 

register UBYTE c,*lwb,*lwn,*end; 

Iwb = NULL; /* Last Word mit Blank */ 

Iwn = NULL; /* Last Word normal V 

end = str '»■ len - 1; /* Zeiger auf String-Ende */ 

for (str += len; len; len--) 

if ((c = *--str) == * •) 
i 

Iwb = str; 
break; 

> 

eise if (! ((c >= *A*) && 

jj (c >= 'a') && 

(c >» '0') && 

11 (c >s 192) j j 

if (Iwn » NULL) 

Iwn = str; 

> 

if (Iwb -= NULL) 
if (Iwn) 

Iwb = Iwn; 


(c <= *Z*) 

(c <= «z«) 

(c <= *9*) 

(c == ' •))) 
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eise 

Iwb = end; 

eise 

if (Iwn) 

if ((end < Iwb) > HAXBREITE / 5) 

if ((end - Iwn + 5) < (end - Iwb)) 

Iwb s Iwn; 

return (Iwb + 1); 

> 

Dabei sucht die Funktion sowohl nach dem letzten Zeichen, vor 
dem ein Blank steht (Iwb « last word blank), als auch nach dem 
letzten Zeichen, vor dem weder ein Buchstabe noch eine Zahl, 
ein Unterstrich oder ein internationales Sonderzeichen steht (Iwn 
= last Word normal). Normalerweise gibt die Funktion Iwb den 
Vorzug. Ist jedoch Iwb zu weit vom String-Ende entfernt (1/5 
der maximalen Breite = 16 Zeichen) und wurde auch ein 
passendes Zeichen für iwn gefunden, so wird Iwn dann der 
Vorzug gegeben, wenn es mindestens fünf Zeichen näher am 
String-Ende liegt als Iwb. Dadurch wird einmal erreicht, daß mit 
Bindestrich getrennte Wörter am Bindestrich aufgetrennt werden, 
sofern das erste Teilwort länger als fünf Zeichen ist, daß aber 
andererseits beispielsweise eine negative Zahl wie "-123" nicht 
ausgerechnet hinter dem Minuszeichen getrennt wird. 

In der Funktion insertChar muß nun zunächst eine kleine Un¬ 
sauberkeit eliminiert werden; Fügt man Tabulatoren am Anfang 
der Zeile ein, und erreicht die Zeile die maximale Breite, so 
werden zwar keine weiteren Tabulatoren mehr eingefügt, aber 
der Cursor wird trotzdem weiter gesetzt. Um dies abzufangen, 
wird die Variable xadd zurückgesetzt, wenn die Länge der Zeile 
die maximale Breite übersteigt. Dazu wurde im folgenden Pro¬ 
grammstück die Zeile "xadd -= ..." erweitert 

/* anz - Anzahl der Blanks, die eingefuegt werden: */ 
if (aktuellerEditor->puflen ♦ anz > MAXBREITE) 
i 

xadd anz aktuellerEditor->puflen - MAXBREITE; 
anz s MAXBREITE - aktueUerEditor->puf len; 

> 

Vor dem Einfügen eines Zeichens in die Zeile wird dann noch 
Wordwrap durchgeführt 
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i* sonst als normales Zeichen: */ 
if ((! aktuellerEditor->skipblanlcs) 

&& (aktuellerEditor’>xpos >= aktueUerEditor->rm)) 

C 

/♦ Uord’Urap nur wenn SkipBlanks == 0 */ 
aktuellerEditor->xpos = getLastWord(aktuellerEditor->puffer, 

aktuellerEditor->puflen) 
- aktuellerEditor->puffer + 1; 
if (! insertLine((UBYTE) 0)) 
return (FALSE); 

if (! saveLine(aktuellerEditor>>aktuell)) 

DisplayBeepC NULL); 

cursorEndO; 

if (! getPufferPointer(&ptr,&inc,&rest)) 
return (FALSE); 

> 

if (aktuellerEditor->insert) 


Daran schließt sich wieder die ursprüngliche Funktion an, es 
wird also das Zeichen in die Zeile eingefügt. Am Ende des Mo¬ 
duls Edit fügen Sie dann noch die Funktion initFolding an: 


y4r*4r1lr*4r***Sr*ar4r***4r4r1^*4r************* 

* 

* initFolding: 

* 


* Berechnet die Falten-Level aller 

* Zeilen ab Textanfang neu. 

* 



void initFoldingO 

< 

register struct Zeile *z; 
register UUORD level,l; 

z s aktuellerEditor->zeilen.head; 
level = 0; 
while (z->succ) 

L 

z->flags = (z->flag8 & ‘"ZLF^FOLD) | (level & ZLF^FOLD); 
if (l s getFoldlnc(z)) 

< 

z->flags I* ZLF.FSE; 
level += l; 

> 
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z = z->succ; 

> 

> 

Damit wären alle Änderungen durchgeführt. Ersetzen Sie nun im 
Make-File die Testumgebung Test durch das neue Modul Com- 
mand, und lassen Sie den Editor übersetzen. Quelltext und ferti¬ 
ges Programm finden Sie wie gewohnt auf der Diskette zum 
Buch, und zwar im Verzeichnis V0.6! Auf den TestText wurde 
diesmal verzichtet, da Sie nun beliebige Texte laden können. 
Schauen Sie sich doch mal den Quelltext des neuen Moduls mit 
dem Editor an: 

cd V0.6 

Editor src/Command.c 

Wir haben dieses und alle anderen Module mit Falten versehen, 
wodurch die Übersichtlichkeit nicht unerheblich gesteigert 
wurde. Sie haben nun auf einen Blick alle Funktionen, die dieses 
Modul enthält, parat und können sich mit Ctrl-F jede dieser 
Funktionen genauer ansehen. 

An dieser Stelle wollen wir - zumindest in diesem Buch - die 
Entwicklung des Editors abbrechen. Wir denken, daß wir Ihnen 
alles Wissenswerte vermittelt haben, das zum Erstellen eines 
größeren Programms auf dem Amiga wichtig und hilfreich ist. 
Vielleicht entwickeln Sie den Editor ja weiter; wir werden es 
auf jeden Fall auch tun. Schließlich haben wir noch viele Ideen, 
die auf ihre Verwirklichung warten. 
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4.4 Befehisübersicht des Editors 


1. Direkte Tastenkommandos 


Cursor-Tasten 

normal 

Bewegen den Cursor um Zeichen bzw. Zeile. 

Shift rechts/links 

Cursor an Zeilenanfang bzw. -ende. 

Shift hoch/runter 

Cursor halbe Seite hoch bzw. runter. 

Delete 

Löscht Zeichen unter Cursor. 

Backspace 

Löscht Zeichen links vom Cursor. 

Tab 

Tabulator einfügen. 

Ctrl-B 

Lösche Zeile. 

Ctrl-E 

Aus Falte heraustreten. 

Ctrl-F 

In Falte eintreten. 

Ctrl-G 

Kommandozeile erneut ausführen. 

Ctrl-H 

Backspace. 

Ctrl-I 

Tab. 

Ctrl-J 

Zeile auftrennen (LF). 

Ctrl-M 

Zeile auftrennen (LF). 


2. Befehie für Kommandozeiie 

AL ["Dateiname”] Laden eines Textes. 

AS ["Dateiname"] Abspeichern des gesamten Textes. 


CB (Cursor Bottom] 
CD (Cursor Down) 
CE (Cursor End) 

CH (Cursor Home) 
CL (Cursor Left) 

CN (Cursor Next) 

CP (Cursor Previous) 
CR (Cursor Right) 

CS (Cursor Start) 

CT (Cursor Top) 

CU (Cursor Up) 


Cursor auf Text“/Faltenende. 

Cursor um eine Zeile nach unten. 
Cursor hinter Zeilenende setzen. 
Cursor auf Zeilenanfang setzen. 
Cursor ein Zeichen nach links. 

Cursor auf Anfang von nächster Zeile. 
Cursor auf Anfang von voriger Zeile. 
Cursor ein Zeichen nach rechts. 
Cursor auf Zeilenanfang setzen. 
Cursor auf Text-/Faltenanfang. 
Cursor um eine Zeile nach oben. 


DB (Delete Back) 
DC (Delete Char) 
DL (Delete Line) 


Backspace. 

Zeichen löschen (Delete). 
Zeile löschen. 
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LS (Line Split) 

Trenne Zeile an Cursor-Position auf. 

Q 

Verlasse Editor. 

Sa 

Auto-Indent aus. 

SA 

Auto-Indent ein. 

Sb 

SkipBlanks aus. 

SB 

SkipBlanks ein. 

Si 

Einfügemodus (Insert). 

So 

Überschreibmodus (Overwrite). 

St 

Tabulatoren aus. 

ST 

Tabulatoren ein. 

X 

Text abspeichern, falls verändert, und Pro¬ 
gramm beenden. 
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Anhang 

Anhang A 

Die häufigsten Routinen der c.iib 

Dieser Anhang gibt einen Überblick über die am häufigsten ge¬ 
brauchten Routinen der Linker-Library c.iib: 


atof 

1) 

atoi 

1) 

atol 

1) 

dose 

3) 

creat 

3) 

getc 

4) 

getchar 

4) 

open 

3) 

printf 

4) 

puts 

4) 

read 

3) 

rename 

3) 

Strien 

2) 

strcat 

2) 

strncat 

2) 

strcmp 

2) 

strncmp 

2) 

write 

3) 
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1. Ziffer-String-Konvertierungen 


atof ABCli nach DOUBLE 


Syntax 

Double = atof (String) 

düble Double; 
char *String; 

Beschreibung 

Diese Funktion konvertiert (iie in einem ASCII-String enthaltene 
Zahl (z.B. String = "1.23445") in eine Double-Variable. 

Parameter 

String: Zu konvertierender Ziffern-String. 

Ergebnis 

Double: Wert des Strings als Double-Variable. 


atol 


ASCII nach Integer 


Syntax 

Integer = atoi (String) 

int Integer; 
char *String; 

Beschreibung 

Diese Routine konvertiert einen Ziffern-String in eine Integer- 
Zahl. 

Parameter 

String: Zu konvertierender Ziffern-String. 
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Ergebnis 

Integer: Integer-Repräsentation des Ziffern-Strings. 


atol 


A$cil nacN Long 


Syntax 

Long = atol (String) 

long Long; 
char *String; 

Beschreibung 

Diese Routine konvertiert einen Ziffern-String in einen Long- 
Wert. 

Parameter 

String: Zu konvertierender Ziffern-String 
Ergebnis 

Long: Long-Repräsentation des Ziffern-Strings. 

2. String-Handling 

strten tJnga d«i Shinga hereohitan 


Syntax 

Länge = strlen (String) 

int Länge; 
char *String; 

Beschreibung 

Diese Routine liefert die Anzahl der Zeichen des angegebenen 
Strings zurück. Der String muß allerdings durch ein Null-Byte 
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abgeschlossen worden sein. Dieses Null-Byte wird nicht mitge¬ 
zählt. 

Parameter 

String: Adresse des zu untersuchenden Strings. 

Ergebnis 

Länge: Anzahl der im String enthaltenen Zeichen. 


stroat 




Syntax 

NeuerString = strcat (Stringl, String2) 

char ‘NeuerString; 
char ‘Stringl; 
char ‘String2; 

Beschreibung 

Diese Funktion verbindet zwei Strings miteinander. String2 wird 
an Stringl angehängt. 

Parameter 

Stringl: Adresse des ersten Strings. 

String2: Adresse des anzuhängenden Strings. 

Ergebnis 

NeuerString: Adresse des zusammengesetzten Strings. 
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strcmp 


V«r] 9 lai^ xwaitt' $frtng[a 


Syntax 

Ergebnis = strcmp (Stringl, String2) 

int Ergebnis; 
char *String1; 
char *String2; 

Beschreibung 

Diese Funktion vergleicht zwei Strings. 

Parameter 

Stringl; Adresse des mit String2 zu vergleichenden Strings. 
String2: Adresse des mit Stringl zu vergleichenden Strings. 

Ergebnis 

Ergebnis: Ergebnis gibt an, ob die Strings gleich (Ergebnis = 0) 
waren, oder ob Stringl lexikographisch größer ist als String2 
(Ergebnis > 0) oder er lexikographisch kleiner ist als String2 
(Ergebnis > 0). 


3. File-Handling 




Syntax 

Error = dose (fd) 

int Error; 
long fd; 


Beschreibung 

Diese Routine schließt ein File. 
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Parameter 

fd: Filedeskriptor, der von open() oder creat() zurückgeliefert 
wurde. 

Ergebnis 

Error: Hat Error den Wert 0, ist alles OK. Bei Error gleich -1 ist 
ein Fehler aufgetreten. 



Syntax 

fd > creat (Name) 

long fd; 
char *Name; 

Beschreibung 

Diese Funktion öffnet ein File, das nur beschrieben werden 
kann. Existierte schon ein File gleichen Namens, so wird das alte 
File gelöscht. 

Parameter 

Name: Name des zu öffnenden Files. 

Ergebnis 

fd: Filedeskriptor, der für close(), read() und write() benutzt 
wird. 
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open 




Syntax 

fd = open (Name, Modus) 

long fd; 
char *Naine 
long Modus; 

Beschreibung 

Diese Routine öffnet ein File. Sie können dann dieses File aus- 
lesen, beschreiben etc. Allerdings müssen Sie für weitere Opera¬ 
tionen immer den Filedeskriptor angeben. 

Parameter 

Name: Adresse des Namens-Strings. 

Modus: Modus gibt an, auf welche Weise das File geöffnet wer¬ 
den soll und wie ein schon mit dem angegebenen Namen exi¬ 
stierendes File behandelt werden soll: 

0_RD0NLY 

Das File kann nur gelesen werden. Es muß also schon existieren. 
OJVRONLY 

Dieses File kann nur beschrieben werden. 

0_RDWR 

Das File kann sowohl beschrieben als auch gelesen werden. 
0_CREAT 

Das File wird erzeugt und dann geöffnet. 

OJTRUNC 

Ein schon mit gleichem Namen existierendes File wird gelöscht 
und neu geöffnet. 
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0_EXCL 

Wenn schon ein File mit gleichem Namen existiert, verursacht 
open() einen Fehler. 

0_APPEND 

Das File wird geöffnet, um an das Ende des bestehenden Files 
noch Daten anzuhängen. 

Die Symbole für Modus werden im Include-File fcntl.h defi¬ 
niert. 

Ergebnis 

fd: fd ist der Filedeskriptor des Files. Über ihn kann das File 
mittels readO, write() und close() bearbeitet werden. Hat fd den 
Wert -1, so ist bei open() ein Fehler aufgetreten. 

Siehe auch: read(), write(), close(). 


read 


Lesal^ie 


Syntax 

Anzahl = read (fd, Buffer, AnzBytes) 

int Anzahl; 
long fd; 
char *buf; 
long AnzBytes; 

Beschreibung 

Dieser Befehl liest Daten vom File des angegebenen Filede¬ 
skriptors. 

Parameter 

fd: Filedeskriptor des Files, aus dem Daten gelesen werden 
sollen. 

buf: Adresse des Speicherbereichs, in den die gelesenen Daten 
hineingeschrieben werden sollen. 
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AnzBytes: Anzahl der Bytes, die aus dem File gelesen werden 
sollen. Diese Anzahl sollte kleiner oder gleich der Größe des 
Puffers sein. 

Ergebnis 

Anzahl: Anzahl gibt die Anzahl der tatsächlich gelesenen Bytes 
an. Ist dieser Wert gleich 0, wurde das Ende des Files erreicht. 






Syntax 

Error = rename (AlterName, NeuerName) 

int Error; 
char *AlterNaine; 
char *NeuerNaine; 

Beschreibung 

Dieser Befehl gibt einem existierenden File einen neuen Namen. 
Parameter 

AlterName: Alter Name des Files. 

NeuerName: Name, den das File erhalten soll. 

Ergebnis 

Error: Hat Error den Wert 0, wurde die Umbenennung erfolg¬ 
reich ausgeführt. Bei Error gleich -1 kann der Fehler aufgetre- 
ten sein, daß ein File mit dem Namen NeuerName schon exi¬ 
stiert. Dann wird das E_EXISTS-Flag in der globalen "errno”- 
Variablen gesetzt, die aufgetretene Fehler näher spezifiziert. 
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writ0 


Daten atir File 


Syntax 

Anzahl = write (fd, Buffer, AnzBytes) 

int Anzahl; 
long fd; 
char *Buffer; 
long AnzBytes; 

Beschreibung 

Diese Funktion schreibt AnzBytes Bytes auf das File, das durch 
den Filedeskriptor näher spezifiziert wird. 

Parameter 

fd; Filedeskriptor des Files, in das die Daten geschrieben werden 
sollen. 

Buffer: Anfangsadresse der Daten, die geschrieben werden 
sollen. 

AnzBytes: Anzahl der Bytes, die auf das File geschrieben werden 
sollen. 

Ergebnis 

Anzahl: Gibt die Anzahl der tatsächlich geschriebenen Bytes an. 
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4. Ein-/Ausgabe 

^totiar 


Syntax 

Zeichen ^ getcharO 
int Zeichen; 

Beschreibung 

Diese Funktion liest das nächste Zeichen vom Standard-Input- 
Stream. Beim Amiga muß allerdings erst <Return> eingegeben 
werden, damit getchar() zum Programm zurückkehrt. 

Ergebnis: 

Zeichen: Eingelesenes Zeichen. 


prlntf 




Syntax 

printf (Koinmando_String, Varl, VarZ, ...); 

char *Koninando String 
.,. Varl 
... Var2 


Beschreibung 

Dieser Befehl dient zur Ausgabe von Nachrichten an den Be¬ 
nutzer. Diese werden in das Standard-Output-File (stdout) ge¬ 
schrieben. Meist ist stdout das CLI-Window. 

Parameter: 

Kommando_String: Neben normalen ASCII-Codes können Sie 
durch Spezialcodes veranlassen, daß Werte von Variablen ausge¬ 
druckt werden können: 
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%d Ausgabe einer Integer-Variablen in dezimaler Notation. 

%o Ausgabe einer Integer-Variablen in oktaler Notation. 

%x Ausgabe einer Integer-Variablen in hexadezimal. Notation. 
%u Ausgabe einer Integer-Variablen ohne Vorzeichen. 

%c Ausgabe eines Zeichens. 

%s Ausgabe eines Strings. 

%f Ausgabe einer Fließkommavariablen (float oder double). 

%e Ausgabe einer Fließkommavariablen (float oder double) in 

wissenschaftlicher Notation. 

%g Ausgabe einer Fließkommavariablen (float oder double) in 
der Notation (dezimal, Fließkomma (normal), Fließkomma 
(wissenschaftlich)), die am wenigsten Platz beansprucht. 

%% Ausgabe des Prozentzeichens. 

Zwischen Prozentzeichen (%) und dem Zeichen, das die 
auszugebende Variable bestimmt, können noch Formatan¬ 
gaben angegeben werden. 

Varl 

Var2 

Dies sind die jeweiligen Variablen, die ausgegeben werden 
sollen. Sie müssen in der Reihenfolge angegeben werden, 
in der sie im Kommando_String spezifiziert werden. 
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Syntax 

puts (String) 
char *String; 

Beschreibung 

Diese Routine gibt einen String auf das Standard-Output-File 
aus. Dabei ist dieser String kein Kommando_String wie bei 
printfO und wird genauso ausgegeben, wie er angegeben wurde. 

Parameter 

String: Adresse des auszugebenden Strings. 
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Anhang B 

Lattice-Compiler* und Linker-Optionen 

Compiier LC 

Der Compiler wird nach folgendem Format auf gerufen: 

Ic [Optionen] Files 

Der Compiler besteht aus zwei Programmen (Icl und lc2), die 

vom Programm Ic automatisch aufgerufen werden. 

Hinweis: Bei der Angabe der zu compilierenden Files können 
Wildcards (#?) und Joker (?) verwendet werden. So 
wird durch den Aufruf von Ic #? dafür gesorgt, daß 
alle C-Sources des aktuellen Verzeichnisses compi- 
liert werden. Nach der Endung .c für C-Sources 
wird dabei automatisch gesucht. 

Hier die Compiler-Optionen: 


-a 

Mit Hilfe dieser Option legen Sie fest, welche Programmbereiche 
in den Chip-Memory geladen werden sollen. Welcher Datenbe¬ 
reich in den Chip-Memory geladen werden soll, muß durch 
einen Buchstaben, der direkt hinter -a angegeben werden muß, 
festgelegt werden. 

b BSS (Block Storage Segment) und uninitialisierte Daten 

c Code-Segment 

d Daten-Segment 

Normalerweise werden alle Segmente ins Fast-RAM geladen. 
Aber bei der Programmierung der Grafik- und Sound-Chips ist 
es notwendig, daß alle Daten im Chip-Memory stehen (-abd). 

-b 

Normalerweise kann man alle Daten eines Programms adressie¬ 
ren. Dies wird möglich durch eine absolute 32-Bit-Adressierung. 
Wenn man allerdings die Option -b verwendet, wird eine rela- 
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tive 16-Bit-Adressierung verwendet. Diese Adressierungsart ist 
zwar schneller als die 32-Bit-Adressierung, legt aber gewisse 
Beschränkungen auf: Um diese Adressierung zu verwenden, ent¬ 
hält das Register A4 die Basisadresse des Datenbereichs (A4 re¬ 
lative Adressierung). Wenn Sie diese Art der Adressierung bei 
eigenen Tasks oder Interrupts benutzen wollen, muß dieses Re¬ 
gister gerettet und neu gesetzt werden (siehe Option -y). Außer¬ 
dem macht die Verwendung einer 16-Bit-Adressierung nur Da¬ 
tenbereiche von maximal 64 KB möglich, die im selben Hunk 
liegen müssen. 

-C 

Wenn Sie mehrere zu compilierende Files angegeben haben, wer¬ 
den Sie beim Auftreten eines schweren Fehlers gefragt, ob wei¬ 
ter compiliert werden soll. Wenn Sie die Option -C (Achtung: 
Großschreibung!) verwenden, wird auf die Abfrage verzichtet 
und automatusch das nächste File compiliert. 

-c 

Mit Hilfe dieser Option können Sie einige Abweichungen vom 
ANSI-C-Standard festlegen. Je nach Buchstabe, der nach -c 
folgt, wird folgende Abweichung festgelegt: 

c Es ist erlaubt, Kommentare zu verschachteln. 

d Das Zeichen $ darf in Symbolnamen verwendet werden. 

m Es ist möglich, Zeichen-Konstanten mit mehr als einem 
Buchstaben anzugeben (z.B. ab). 

s Von identischen Strings wird nur eine Kopie angelegt. 

t Wenn bei der Definition eines Zeigers auf eine Struktur 
festgestellt wird, daß die Struktur nicht definiert wurde, 
wird normalerweise eine Warnung ausgegeben. Diese Op¬ 
tion verhindert dies allerdings, so daß 

struct ABC *Pointer; 

erlaubt ist, obwohl ABC nicht definiert wurde. 

u Alle char-Deklarationen werden in Unsigned-Char-De- 
klarationen umgewandelt. 
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w Diese Option schaltet die Generierung von Warnings ab, 
wenn bei einer INT-Funktion die Rückgabe des Rückga¬ 
bewertes mit returnO vergessen wurde. INT-Funktionen 
werden also wie VOID-Funktionen gehandhabt. 

-dSYMVBOL[^WERTJ 

Mit Hilfe dieser Option können Sie nachträglich eine Konstante 
definieren (#define). 

-/ 

Diese Option veranlaßt den Compiler, die Motorola-Fast-Floa- 
ting-Point--Routinen (mffp) zu verwenden (bei FLOAT- und 
DOUBLE-Variablen). Normalerweise werden die lEEE-Routinen 
benutzt. Beachten Sie, daß IEEE und MFFP nicht kompatibel 
sind! Bei Verwendung der Option -f muß außerdem die 
Icmffp.lib beim Linken verwendet werden. 

-h 

Mit Hilfe dieser Option können Sie festlegen, welches Segment 
ins Fast-RAM geladen werden soll: 

b BSS und uninitialisierte Daten, 
c Code-Segment, 

d Datensegment. 

Mit -hbcd wird dafür gesorgt, daß das ganze Programm ins 
Fast-RAM geladen wird. 

-/ 

Mit Hilfe dieses Kommandos können Sie nachträglich festlegen, 
welche Disketten und Verzeichnisse nach Include-Files durch¬ 
sucht werden sollen (z.B. -idfO:Meine:Incs/). Normalerweise wird 
das mit der Umgebungsvariable INCLUDE: spezifizierte Ver¬ 
zeichnis durchsucht. Mit der Option -i haben Sie allerdings die 
Möglichkeit, bis zu 10 weitere Verzeichnisse anzugeben (-iVerzl: 
-iVerz2: usw.). 
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-L 

Mit Hilfe dieser Option wird veranlaßt, daß der Linker automa¬ 
tisch vom Compiler aufgerufen wird. Standardmäßig werden der 
Startup-Code (c.o), sowie die Librarys Ic.lib und amiga.lib beim 
Linken verwendet. 

Nach -L kann ein weiterer Buchstabe angegeben werden, der die 
Arbeitsweise des Linkers beeinflußt: 

c Es wird die Smallcode-Option des Linkers verwendet. 

d Es wird die Smalldata-Option des Linkers verwendet. 

f Es wird neben Ic.lib und amiga.lib die Icmffp.lib beim 
Linken verwendet. 

m Es wird die Im.lib verwendet (lEEE-Mathematik-Routi- 
nen). 

V Verbose-Option des Linkers. 

Beim Aufruf des Comilers mit der Option -L wird ein File mit 
der Endung .Ink erzeugt. Dieses File wird zur Übergabe der Op¬ 
tionen an den Linker verwendet. Sie können dieses File verän¬ 
dern (mit dem ED) und den Link-Vorgang einfach durch 
BLINK xxxx.lnk erneut starten. 

-/ 

Mit Hilfe dieser Option wird der Compiler veranlaßt, alle Vari¬ 
ablen außer char und short int an durch 4 teilbaren Adressen 
beginnen zu lassen (BCPL-Kompatibilität). 

-M 

Mit Hilfe dieser Option werden nur die Files compiliert, deren 
Objekt-File älter als das zugehörige Source-File ist (siehe Make 
beim Aztec). Wie auch beim Make-Utility werden Änderungen 
in (eigenen) Includes hierbei nicht berücksichtigt. Wenn Sie also 
ein eigenes Include-File verändert haben, ohne das zugehörige 
Source-File zumindest in den ED (oder einen anderen Editor) 
geladen und wieder abgespeichert zu haben, wird diese Ände¬ 
rung nicht berücksichtigt. 
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-o 

Mit Hilfe dieser Option können Sie festlegen, in welches Ver¬ 
zeichnis oder unter welchem Namen das vom Compiler erzeugte 
Objekt-File geschrieben werden soll (z.B. -odhO: oder - 
odhOiobjekt.o). 

-Q 

Mit Hilfe dieser Option legen Sie fest, wohin die temporären 
Files des Compilers geschrieben werden sollen (siehe QUAD: 
Umgebungsvariable). 

-r 

Mit Hilfe dieser Option wird der Compiler dazu veranlaßt, zur 
Adressierung die PC-Relative-Adressierungsart zu verwenden. 
Dies hat den Nachteil, daß Routinen, die angesprungen werden 
sollen, in einem Bereich von +/-32K vom Aufruf liegen müssen. 
Diese Adressierungsart ist nützlich für kleinere Programme. Bei 
größeren Programmen, wo die Zieladressen außerhalb dieses 
Bereichs liegen, muß eine "Übersetzung" des Sprungs durchge¬ 
führt werden, was zur Verlangsamung des Programms führt oder 
dafür sorgt, daß das Program nicht vom Linker erzeugt werden 
kann. 

-R 

Mit Hilfe dieser Funktion können Sie dafür sorgen, daß die vom 
Compiler erzeugten Objekt-Files direkt in eine eigene Library 
geschrieben werden. Routinen, die vorher schon in der Library 
existierten, werden hierbei überschrieben. Nach -R muß der 
Name der Library erfolgen (-RMeineLib.Lib) - inklusive des 
Tags .lib. 

-s 

Normalerweise sind alle Hunks, die vom Linker erzeugt werden 
und das lauffähige Programm ausmachen, unbenannt. Mit Hilfe 
dieser Option wird aber dafür gesorgt, daß im Objekt-File die 
Namen text, data und udate für die Code-Hunks, Data-Hunks 
und BSS-Hunks vergeben werden, was wiederum dazu führt, 
daß der Linker diese Namen bei der Programm bzw. Hunkgene- 
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rierung verwendet. Wenn Sie andere Namen als text, data und 
udata verwenden wollen, müssen Sie nur die Optionen 

-sc=Codehunk 

-sd=:Datahunk 

-SB=Bsshunk 

verwenden. Die Symbole Codehunk, E>atahunk und Bsshunk 
werden dabei von Ihnen durch Strings ersetzt. 

-V 

Mit Hilfe dieser Funktion wird die Überprüfung des Stacks 
beim Eintritt in jede Funktion ausgeschaltet. 


-X 

Alle globalen Variablen werden als externe Variablen deklariert. 
Somit können von verschiedenen Modulen aus dieselben Vari¬ 
ablen verwendet werden. 

-y 

Wenn Sie diese Option verwenden, wird bei jedem Eintritt in 
eine Funktion das Register A4 mit der Basisadresse der Vari¬ 
ablen geladen (siehe Option -b). 


Linker BLINK 

Der Linker wird nach folgendem Format auf gerufen: 

BLINK [FRONICROOT] Files [TO File][UITH File][VER File] [LIBRARY 
oder LIB Files][XREF File][Optionen] 

Wie Sie sehen, können nach einem Schlüsselwort ein oder meh¬ 
rere Files folgen. Mehrere Files werden dabei entweder durch 
ein Leerzeichen oder duch ein + getrennt. 

Neben den oben beim Aufruf des BLINK angegebenen Schlüs¬ 
selwörtern erkennt der BLINK noch eine Menge weiterer 
Schlüsselwörter. Diese werden als Optionen angebenen. Hier eine 
alphabetische Liste der BLINK-Schlüsselwörter: 
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ADDSYM 

Dieses Schlüsselwort veranlaßt BLINK, einen Symbol-Hunk zu 
generieren, der von symbolischen Debuggern (DB oder Metas- 
cope) verwendet wird, um Variablen, Routinen usw. symbolisch 
(also mit deren Namen) ansprechen zu können. 

BATCH 

Alle Undefinierten Symbole werden auf 0 gesetzt. Normalerweise 
unterbricht der Linker seine Arbeit, wenn er auf ein Undefi¬ 
niertes Symbol trifft. 

BUFSIZE n 

Dieses Schlüsselwort bestimmt, wie groß der I/O-Buffer wäh¬ 
rend des Linkens sein soll. Normalerweise ist der Buffer 488 
Bytes groß (ein Datensektor). Wenn Sie diesen Buffer ver¬ 
größern, können mehr Daten auf einmal vom Linker gelesen 
werden. Dies hat den Vorteil, daß der Linker schneller arbeiten 
kann, da mehr Daten im Speicher stehen und nicht erst von Dis¬ 
kette geladen werden müssen. 

CHIP 

Mit Hilfe dieses Schlüsselwortes können Sie dafür sorgen, daß 
alle Hunks des Programms in den Chip-Memory geladen werden. 

FAST 

Mit Hilfe dieses Schlüsselwortes wird dafür gesorgt, daß alle 
Hunks in das Fast-RAM des Rechners geladen werden (siehe 
Chip). 

FROM/ROOT 

Die nach diesen beiden Schlüsselwörtern stehenden Files be¬ 
stimmen die Objekt-Files, die zu Beginn des lauffähigen Pro¬ 
gramms stehen sollen. Zu beachten ist, daß mindestens ein Ob¬ 
jekt-File angegeben werden muß. Meistens verwendet man aber 
mehrere, da das erste Objekt-File immer das File c.o ist, das 
den Startup-Code enthält, der dafür sorgt, daß die Kommando- 
Parameter für die Routine main() aufgearbeitet werden, und die 
Möglichkeit besteht, das Programm mit exit() zu verlassen. 
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Außerdem sorgt c.o dafür, daß der Stack beim Start und Ver¬ 
lassen des Programms korrekt verwaltet wird. 

LIB/LIBRARYS 

Die nach diesen Schlüsselwörten definierten Files bestimmen die 
Libararys, die durchsucht werden sollen. Wie zu Beginn dieses 
Buches schon erwähnt, werden die Librarys Ic.lib und amiga.lib 
immer verwendet, denn diese enthalten erstens alle C-immanen- 
ten Funktionen (strlen(), strcmp() etc.) sowie die Aufrufe der 
Amiga-Betriebssystemroutinen. E)er Unterschied zwischen Ob¬ 
jekt-Files und Libararys ist folgender: Objekt-Files werden in 
Ihrer Gesamtheit zum Programm gelinkt - es werden also auch 
Routinen eingebunden, die gar nicht angesprungen werden. Li¬ 
brarys hingegen werden nach den noch nicht in den Objekt-Mo¬ 
dulen definierten Routinen durchsucht. Zum Programm werden 
dann nur die tatsächlich verwendeten Routinen gelinkt. 

NODEBUG/ND 

Mit Hilfe dieses Schlüsselwortes wird die Erzeugung des Hunks 
HUNK_DEBUG unterdrückt. 

NOALVS 

Mit Hilfe dieses Schlüsselwortes wird die Erzeugung einer 32- 
Bit-Sprungtabelle zur Auflösung von 16-Bit-Sprüngen verhin¬ 
dert. Dieses Schlüsselwort wird verwendet, wenn Sie sichergehen 
wollen, daß ein tatsächlich relokatibles Programm erzeugt wird. 
Wenn der Linker feststellt, daß ALV (Automatic Load Vectors) 
erzeugt werden müssen, damit das Programm laufen kann, un¬ 
terbricht BLINK seine Arbeit. 

SMALLCODE/SD 

Mit Hilfe dieser Schlüsselwörter wird dafür gesorgt, daß alle 
Code-Hunks zu einem einzigen zusammengeschlossen werden. 

SMALLDATA/SD 

Mit Hilfe dieser beiden Schlüsselwörter wird dafür gesorgt, daß 
alle Daten-Hunks (initialisierte und uninitialisierte (BSS) Daten) 
zu einem Hunk zusammengefaßt werden. 
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TO 

Das File, das nach diesem Schlüsselwort angegeben wird, be¬ 
stimmt, welchen Namen das lauffähige Programm erhalten soll. 
Oder anders gesagt: Dieser File-Name bestimmt, zu welchem 
File die angegebenen Objekt-Files und Library-Routinen zu¬ 
sammengebunden werden sollen. 

VERIFY/VER 

Mit Hilfe dieses Schlüsselwortes können Sie ein File festlegen, in 
das alle Linker-Nachrichten geschrieben werden sollen. Geben 
Sie dieses Schlüsselwort nicht an, wird der Bildschirm zur Aus¬ 
gabe benutzt. 

VERBOSE 

Mit Hilfe dieses Schlüsselwortes können Sie den Linker veran¬ 
lassen, den Namen jeder Routine auszugeben, die gerade unter¬ 
sucht wird. 

XREF 

Mit Hilfe dieses Schlüsselwortes legen Sie fest, wohin das Cross- 
Reference-Listing geschrieben werden soll. 
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Stichwortverzeichnis 

<exec/memory.h>. 499 

= . 128, 144 

< . 128, 145 

> . 128, 145 

» . 128, 145 

? . 129, 145 

640*512 Punkte . 282 

720*452 Punkte . 263 

68000er . 496 

8 MByte . 497 

Abfrageroutine . 365 

Abhängigkeiten . 522 

Acc. 136 

ACCESS_READ . 164 

ACCESS_WRITE . 164 

Acd . 136 

Acs . 136 

Add . 119, 137 

ADDR. 117, 134 

Adi . 119, 137 

Adl . 119, 137 

Adp . 119, 137 

Adr . 119, 137 

Adresse . 503 

Ae . 137 

Ai . 119 

Ak . 119 

Aktivierungsbereich. 428 

Al . 120 

Alert-Nummer . 378 

Alert-String . 379 

Alert-Struktur . 380 

Alert-Text . 379 
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Alert-Typ . 378, 382 

Alerts . 377 

Alt ... 414, 485, 486, 494 

Am . 120, 137 

Amiga-Symbol . 432 

Amiga-Taste. 432 

An . 120 

Ap . 120 

Aq . 120 

Ar. 121 

As . 121 

ASCII . 436, 448 

ASCII-Code . 430, 475 

ASCII-Ziffern . 475 

Assembler . 217 

Assembler . 453 

Assembler-Code . 451, 563 

Assembler-Modus . 494 

Assembler-Optionen . 100 

At . 121 

Audio.Device. 391 

Auflösung . 260 

Augenschmerzen . 261 

AUSDR . 116, 134 

Ausgabe aller Files . 178 

Ausgabe-Window . 418 

Ausgaben . 261 

Auto-Indent . 634 

Automatik-Requester . 359 

AutoRequest . 377 

AutoRequester . 363, 378 

Ax . 137 

Aztec-DB . 112 

Aztec-Source-Level-Debugger . 129 

Aztec-Compiler. 17 

BACKDROP-Window . 210 

Backspace-Taste. 478 

BackspaceChar . 633, 645 

Baukastensystem . 285 
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Bb . 

Bc .. 

Bd . 

Be . 

BECKERtext .... 

BEREICH . 

Betriebssystem .. 

Bh . 

Bildschirmzeilen 

Bit-Gruppen. 

BitMap . 

BitPlanes . 

Bl . 

Blockstift . 

Boolean-Gadgets 

Booten . 

Border . 

Border-Struktur 
BORDERLESS . 

Bq . 

Br . 

Breitschrift . 

Bs . 

Bt . 

Bu . 

Bw . 


. 121 

. 122, 138 

. 122, 138 

. 138 

. 308 

. 118, 135 

. 386 

. 122 

. 379 

. 408 

. 209, 265, 267 

. 301 

. 121 

. 206 

. 314 

. 204 

. 209 

294, 295, 322, 324 

. 209 

. 123 

. 123, 139 

. 289 

. 123, 139 

. 123, 139 

. 123 

. 121 


C . 139 

C-Code . 451 

C-Prdgramm. 217, 453 

C-Quelltext . 453 

C-Quelltext-Editor . 284, 305 

Cancel . 364 

CapsLock-Taste . 494 

Cast-Anweisung . 221 

Casting . 537 

CheckMark . 207 

Checkmark . 440, 453 

Chip-Memory . 305, 347 

Chip-RAM . 496 
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CHIP MEMORY . 



282 

CLI. 



478 

CLI-Editor . 



483 

CLI-Fenster. 



305 

Clipboard.Device . 



391 

Clipping . 



570 

Close-Gadget. 

. 210, 

213, 

270 

Close All(). 

. 230, 

231, 

270 

CloseEditor ... 



535 

CMDLISTE . 


119, 

135 

Cn utoa . 



686 

CommandASCII . 



698 

CommandBracket . 



703 

CommandCursor . 



699 

CommandDelete . 



700 

CommandExit . 



703 

CommandLine . 



701 

CommandQuit . 



701 

CommandSet. 



701 

Compiler . 



302 

Compiler-Optionen . 



57 

Console.Device . 

. 391, 

467, 

468 

ConsoleBase . 



539 

ConsoleReadMsg-Struktur . 



470 

ConsoleWriteMsg-Struktur . 



470 

Container . 



328 

ConvertLineForPrint . 

. 574, 

583, 

661 

ConvertSpstToZeile . 

. 549, 

555, 

562 

Cs . 



124 

CSI . 


475, 

479 

Ctrl . 

. 414, 485, 

486, 

494 

Ctrl-C . 



182 

Cursor . 


599, 

603 

Cursor-Position . 


475, 

480 

CursorBottom . 



727 

CursorDown . 


598, 

610 

CursorEnd . 



725 

CursorHome . 



666 

CursorLeft . 


598, 

609 

CursorOnText. 



636 
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CursorRight . 598, 609 

CursorTop . 726 

CursorUp . 598, 610 

Custom-Chips . 497 

Custom-Gadget . 266, 276 

CustomRequester . 366 

CustomScreen . 207, 265 

D . 124, 140 

Da . 139 

Daten lesen und schreiben . 156 

Datenleitungen . 469 

Datenpuffer. 477 

Datenstrukturen . 513 

Datentransport. 399 

Db . 124, 140 

De . 124, 140 

Dd . 124, 140 

Debugger . 217, 625, 672 

DeconvertLine. 637 

Default-Font . 288 

Default-Struktur . 307 

Default-Struktur-Werte . 307 

Default-Werte . 222 

Default-Zeichensatz . 424 

DefaultTitle . 274 

Deklarieren . 538 

DelayQ . 231 

DeleteChar. 633, 644 

DeleteLine . 634, 653, 732 

Delta-Werte . 280 

Depth-Arrangement-Gadgets . 213 

DEVICE STATUS REPORT . 480 

Df. 140 

Dg . 124, 140 

Directorys anzeigen . 174 

Diskfont.library. 288, 289 

Dl . 124, 140 

DMRequest. 376, 407 

Doppelkasten . 294 
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DOS. 216, 477 

DOS-Fenster. 361 

DOS-Window . 326, 337, 378 

Double-Menu-Requester. 375 

Drag-Gadget . 213 

Dringlichkeit . 377 

Ds . 125, 141 

Dw . 124, 140 

E . 144 

Editor.pre . 520 

Editor.prelist . 520 

Editorfenster . 485 

Effizienz . 590 

Ein- und Ausschalten. 314 

Einbinden von Assembler-Programmen . 685 

Eindimensional. 314 

Eingebundene Message-Struktur . 399 

Einzel-Code . 491 

EnterFold . 664 

Erstellungsdatum. 170 

Exec/types.h . 537 

ExecuteCommand . 704 

Exit . 154 

ExitFold. 665 

Fachliteratur. 470 

Falten-Level. 596, 658 

Faltenanfangsmarkierung . 595 

Faltenende . 595 

Farbauswahl . 453 

Farbauswahl-Untermenü. 443 

Farbbalken . 443 

Farbe. 260 

Farbstifte . 236 

Fast-RAM . 496 

Fd. 141 

Fehlerklasse . 388 

Fehlermeldung . 388, 503 

Fehlerquelle . 386 
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Fehlersuche . 629 

Fettschrift. 289 

File-Arbeit . 451 

File-Handling . 152 

File-Informationen . 162 

File-Select-Box . 349f, 359, 369, 417 

FilelnfoBlock . 165 

FileLock . 174 

Fließtext . 724 

Folding . 512, 575, 593 

FreeSpeicherblock . 547, 554 

Freigaberoutine . 499 

Fu. 141 

Funktions-Offset . 217, 278 

Funktionstabellen . 149 

G . 141 

Gadget-Abfrage . 270, 404 

Gadget-Struktur . 266, 321 

GADGHIGHBITS . 316 

Gameport.Device . 391 

GarbageCollection. 546, 551, 556, 707 

Geisterschrift . 419 

Gesamtlänge . 217 

GetFoldlnc . 638 

GetLastWord . 733 

GetLineForEdit. 632, 636 

GetPufferPointer . 643 

Ghosted . 419 

GIMMEZEROZERO . 211, 570 

GIMMEZEROZERO-Window . 212 

Graphics.library . 285 

Grafik-Menüpunkt . 435 

Grafikausgabe .261 

Grafikprogramme . 248 

Grafikspeicher . 209, 282 

Grafikverwaltung. 453 

Graphics.library . 392 

Grundtyp . 315 

Grundvoraussetzungen. 261 
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Guru-Meditation . 377, 386 

Guru-Nummer . 386 

Half PageDown . 611 

Half PageUp . 611 

HAM . 261, 265 

HandleKeys . 599, 612, 666 

Hauptprogramm . 535 

Hauptschleife . 537 

Hexadezimal . 217 

Highlighting-Flags . 434 

HoleZeile . 545, 550 

IDCMP. 391, 468 

IDCMP-Flag. 325, 364, 376, 398, 411 

If-Befehl . 479 

IFF . 436, 448 

Image-Struktur. 300, 302, 322 

Include-File. 379 

Informationsaustausch . 203, 312 

Infozeile. 684 

InitFolding. 735 

InitWindowSize . 575, 582 

Inner window . 211 

Input.Device . 391 

InsertChar. 633, 646 

InsertLine . 633, 649 

Interlace-Screen . 283 

IntuiMessage-Struktur . 398 

IntuiText-Struktur . 287, 290, 306, 323, 440 

Intuition-Library . 473 

Intuition.library. 215, 242, 285 

INVERSEVID . 286, 295 

loErr . 158 

lOStdReq . 472, 488 

lOStdRequest-Struktur . 469, 484 

ITEMNUM . 408 


JAMl, JAM2 
Joker . 


286, 295 
. 180 
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Keyboard.Device . 391 

KeyMap-Belegung . 488 

KeyMap-Struktur . 488 

Kickstart-ROM .. 496 

Klickfelder . 294, 313 

Klickimpuls . 313 

Klickpunkt . 236 

Knobs . 328 

Kommando-Sequenz . 435, 438, 475 

Kommando-Taste .429 

Kommandozeilen-Parameter . 149 

Kommunikation . 203 

Kommunikationskanal . 364 

KONSTANTE . 116 

Koordinatenauswahl . 467 

Koordinatentabelle. 296 

Kursivschrift . 289 

Kurzschreibweise . 240 

Lattice-Compiler . 51 

Laufwerk .417 

Ld . 141 

Lese-Funktion. 472 

Link-Pointer . 423 

Linke Maustaste . 313 

Linker-Optionen 

Linkpointer . 273 

LI . 141 

LoadASCII.695 

Lock. 164 

LoescheZeile . 561 

Lokale Variablen in Blöcken .676 

Lp . 141 

Ls . 125 

Ma. 125 

Main . 535, 718 

MainQ . 231, 240 

Make . 23, 520, 542 

Make-File. 521 
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Maus-Cursor . 236, 429 

Mauskoordinaten. 234, 405 

Mauspfeil. 428 

Maustaste . 411, 426 

Maximalwerte. 234 

Maximum . 206 

Mb . 126, 142 

Mc . 126, 142 

Medium . 418 

Mehrere . 510 

MEMF CHIP . 497 

MEMF_FAST . 497 

MEMF PUBLIC . 497 

Menu-Strip . 423 

Menu-Struktur . 424 

Menuitem-Kette . 436 

Menultem-Struktur. 427, 432, 436 

MENUNUM . 408 

MENUPICK-Flag . 407 

Menü-Überschrift . 429 

Menüleiste . 426, 436 

Menüpunkt . 428 

Menüs . 417 

Menütaste . 426 

MessagePort. 529 

MessageWaiting . 704 

Mf . 126, 142 

Minimalwerte. 234 

Minimum . 206 

Ml . 126, 142 

Mm . 126, 142 

MODE_NEWFILE . 153 

MODE_OLDFILE . 153 

Modulsystematik . 205 

Ms . 126, 143 

MsgPort-Strukturen . 400 

Multi-Alert . 383 

Multitasking-Betriebssystem . 377 

Multitasking-Computer . 402 
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MutualExclude . 429, 440 

Mw. 126, 142 

Narrator.Device . 391 

Nb . 126 

Nd . 126 

NeuerBlock. 544, 547 

NeueZeile . 543, 553 

Neustart . 386 

NewCLI-Window . 476 

NewScreen-Struktur . 262, 267, 270 

New Window-Struktur. 216, 220 

NextLine. 578, 616 

No . 126 

Null-Byte . 473 

Null-Pointer . 402, 497 

Numericpad . 415 

NX . 126 

Offsets . 271, 292 

Open . 152 

Open_All() . 230, 231, 270 

OpenEditor . 534, 579, 714 

OptimiereBlock . 551, 556 

Optimieren . 564 

Option +H . 520 

Option +I . 520 

öffnen von Dateien . 152 

PAL-Fernseher . 282 

PAL-Version . 264 

Parallel.Device. 391 

Pointerfeld. 306 

PowerWindows . 450 

Präcompilieren . 520 

Preferences . 288 

Preferences-Menü . 451 

PrevLine . 579, 617 

PrintAll . 573, 586 

PrintAnzZeilen . 689 
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PrintAt . 

Printer.Device . 

PrintFlags . 

PrintFold . 

Printinfo . 

PrintLine . 

PrintXpos . 

PrintYpos . 

Proplnfo-Struktur ... 
Proportional-Gadget 

Proportionen . 

Protection-Bit . 

Prozessor-Trap . 

Puffern . 


. 575, 584, 622 

. 391 

. 690 

. 690 

. 691 

574, 586, 622, 661 

. 688 

. 689 

. 327, 330 

. 326 

. 314 

. 171 

. 388 

. 208 


Q . 127, 143 

Qualifier . 414, 487, 493 

Quelltext . 453, 494 

R . 127, 143 

RastPort . 291 

RAWKEY . 414, 530 

RAWKEY-Abfrage . 467 

RAWKEY-Codes . 485, 488 

Read. 157 

Read-Port . 468 

RecalcTopOfWindow . 663 

Refresh-Mode . 250 

Regel. 524 

REGISTER . 116 

Register-Variablen . 676 

Remember-Struktur. 503 

Rename-Window. 406 

Repeat-Status .415 

Report. 488 

Requester. 358, 359 

Requester-Gadget . 359 

Requester-Struktur . 367 

Requester-Window . 364 

RestoreZeilenptr . 602 
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Retry. 364 

Return . 477 

Return-Taste . 337, 451 

RETURNERROR. 155 

RETURN_FAIL . 155 

RETURN_OK . 155 

RETURNWARN. 155 

RMBTRAP . 411 

ROM-Font . 288 


S . 

SaveASCII. 

SaveIfCursorMoved . 

SaveLine . 

Schalter in der Kommandozeile 

Schiebebalken. 

Schiebekasten . 

Schließen von Dateien . 

Schriftarten . 

Schriftbreiten . 

Schrifttyp . 

Screen . 

Screen-Struktur . 

Screen-Titel. 

ScrollDown . 

Scrollen . 

Scrollen . 

Scrolling . 

ScrollLeft. 

ScrollRight. 

ScrollUp . 

SDB-Optionen . 

Select-Box . 

SELECT-Flag. 

Select-Gadget . 

Serial.Device . 

SHELL . 

Shift . 

Signal . 

SIMPLE REFRESH . 


. 127, 143 

. 694 

. 632, 642 

. 632, 639 

. 147 

. 206, 326 

. 315 

. 152 

. 440 

. 440 

. 440, 448 

. 260 

267, 270, 271, 274 

. 266, 274 

. 598, 607 

. 212 

. 481 

. 594 

. 598, 605 

. 598, 603 

. 598, 606 

. 130 

. 428, 432, 435 

. 344 

. 345 

. 391 

. 718 


414, 481, 485, 486, 494 

. 537 

. 208, 569 
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Sizing-Gadget . 213 

SMART_REFRESH . 208, 569 

Sonderzeichen. 512 

Source-Code-Utility . 449 

Speicherausführung . 378 

Speicherbedarf . 208 

Speicherbereiche . 496 

Speicherorganisation . 496 

Speicherplatz .. 208 

Speicherstueck. 555 

Speichertyp . 503 

Speicherverwaltung . 495 

Speicherverwaltung . 509, 543 

Sprites . 236 

Sprungstärke . 329 

Src/Ausgabe.c . 581 

Src/command.c. 692 

Src/Cursor.c . 601 

Src/Edit.c . 634 

Src/Editor.c . 532 

Src/Editor.h. 530 

Src/Speicher.c . 546 

Src/Test.c . 557 

Startposition . 295 

StdlOs . 468 

Steuersequenzen . 473, 475, 479 

Steuertasten . 491 

String . 266, 473, 488 

String-Gadget. 331, 406, 683 

Stringlnfo-Struktur . 331 

Struct BList . 517 

Struct Editor . 517, 600 

Struct EList . 532 

Struct FList . 516 

Struct Speicherblock . 515 

Struct Speicherstueck. 515 

Struct Zeile. 513 

Struct ZList . 517 

SUBITEM . 408 

Subitems . 438 
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Subsystem-Liste . 

SucheSpeicherstueck 
SUPER BITMAP .. 

SwitchO . 

Systemabsturz . 

System-Gadgets. 

System-Grafik . 

System-Requester .. 
Systemzeit . 


. 388 

. 548, 554 

. 208, 212 

. 326 

. 426 

. 206, 212, 313 

. 406 

358, 360, 364, 377 
. 196 


T . 

Tabulator . 

Tabulatoren . 

Tastaturwiederholfunktion 

Tastatur-Codes . 

Tastaturbelegung . 

Tastatureingaben . 

Tastaturtabelle. 

Tastenkombination . 

TERM. 

Text . 

Text-Menüpunkt. 

TextAttr-Struktur . 

Textbearbeitung . 

Texteditor . 

TEXTOMAT . 

Textpuffer . 

Textpuffer-Funktionen ... 

Textverarbeitung . 

Timer.Device . 

Titel . 

Titelleiste. 

Titeltext-String. 

Toggle-Gadgets . 

Topaz.font . 

Trackdisk.Device . 


. 127, 143 

. 451, 594, 630 

. 511 

. 539 

. 470 

. 417 

. 470 

. 485, 488 

. 494 

. 116 

. 436, 448 

. 435 

. 266, 288, 289, 440 

. 633 

. 205 

. 308 

. 472, 498 

. 482 

208, 241, 248, 261, 425, 436 

. 391 

. 235 

. 211, 265 

. 274 

. 341 

. 289, 290 

. 391 


U . 127, 143 

UND-Verknüpfung . 342 

UNDO . 315 
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Undo-Puffer . 353 

UndoLine . 633, 642 

Untergrund.261 

Untermenü . 431, 439 

Unterstreichen. 289 

User-Gadget. 324, 352 

V . 128 

VO.l . 542 

V0.2 . 568 

V0.3 . 590 

V0.4 . 625 

V0.5 .672 

V0.6 . 736 

VANILLAKEY. 415 

VANILLAKEY. 530 

VANILLAKEY-Abfrage . 467 

Variablenfeld . 495 

Verkettung . 236, 509 

Version 1,2 . 242 

Version 1.8 . 276 

Verwaltungsaufwand . 508 

Video-Chip . 262, 265 

Wahrheitswert . 366 

WaitO . 325 

Wait-Status . 325, 403 

Wiederholfunktion .495 

Wildcards . 180 

Window-Puffer . 477 

Window-Struktur . 233 

Window-Titel . 211 

Wordwrap . 734 

Workbench. 262 

Workbench-Diskette . 288 

Workbench-Menüs .418 

Workbench-Screen ... 262, 265, 314 

Workbench-Windows .205 

Write . 157 

Write-Port . 468 
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X . 128, 144 

Z . 144 

Zeichen-Codes . 473 

Zeichenfarbe . 306 

Zeichensatz. 266, 288, 306 

Zeichensatzeinstellung . 420 

Zeichenstift . 206, 425 

Zugriff auf absolute Speicherstellen . 146 

Zweidimensional . 314 

Zwischenspeicherung . 208 























Bücher zum Amiga 


Von der Hardware über den Betriebssystemkern EXEC bis 
zum DOS finden Sie in diesem Buch die entscheidenden In¬ 
formationen zum Amiga. Und zwar so verständlich, daß 
auch Nicht-Profis die Arbeitsweise des Amiga-Betriebssy- 
stems schnell verstehen werden. 


Aus dem Inhalt: 

- die Chips des Amiga (68000, CIA, Agnus, 
Denise, Paula) 

- Die Schnittstellen (Video, Audio, RGB, 
Centronics, seriell. Floppy, Gameport, 
Expansionport, Tastatur) 

“ Programmierung der Hardware 
(Speicherbelegung, Interrupts, Copper, 
Blitter, Diskcontroller) 

- Strukturen des EXEC (Node, List, Libraries, 
Tasks) 

- Funktion des Multitasking (Task-switching, 
Kommunikation zwischen Tasks, 
Exceptions, Traps, Speicherverwaltung) 

- I/O-Handhabung beim Amiga durch Devices 
und I/O-Request) 

- Interrupt-Handhabung und Verwaltung der 
Ressources 

- RESET-feste Programme und Strukturen, 
Dokumentation der RESET-Routine 

- EXEC-Base (Dokumentation und Nutzung der Systemvariablen) 

- DOS-Bibliothek (Funktionen, Parameter, Fehlermeldungen) 

- Disketten (Bootvorgang, Datenstrukturen, Programmaufbau, IFF-Format) 

- Programmstart, Parameter, Aufruf von CLI und Workbench, detaillierte Beschreibung 
des internen Aufbaus der CLI-Befehle (interne DOS-Blbllothek) 

- Eln-/Ausgaben (Tastatur, Bildschirm, Diskette, parallele und serielle Schnittstelle) 

- Devices (Trackdisk, Console, Narrator, SER, PAR, PRT, Gameport) 



iMfi M 


AMIGA 


Dittrich, Gelfand, Schemmei 
AMIGA Intern 

Hardcover, 716 Selten, DM 69,- 
ISBN 3-89011-104-1 






Bücher zum Amiga 


Dieses DATA BECKER Floppybuch beschreibt alles Wissenswerte 
zum Thema Floppy ausführlich und sofort nutzbar. Zusätzlich fin¬ 
den Sie in diesem Buch Insider-Informationen über Kopierschutz, 
Speed-Routinen und Viren, die in einschlägigen Kreisen für Aufse¬ 
hen sorgen werden. Daß diese Informationen in einfach zu bedie¬ 
nende Programme umgesetzt wurden, macht dieses Buch zu 
einer unersetzlichen Hilfe bei der täglichen Arbeit mit dem Amiga. 



DATABECKER 

AMIGA 


Aus dem Inhalt: 

- Floppy-Operationen unter Workbench und 
CU 

- BASIC: Laden, Speichern, sequenzielle und 
relative Dateien 

- DOS-Funktionen 

-- Fileverwaltung: Blocktypen, Boot-Block, 
Checksummen, File-Header, Hash-Berech- 
nung, Bitmap 

- Viren: Boot-Block und Schutz 

- Trackdisk-DevIce: Befehle, Strukturen, 
Nachrichten 

- TrackdIsk-Task: Funktion und Aufbau 

- Diskettenzugriff ohne DOS: MFM, GCR, 
Aufbau von Tracks, Block-Header, 
Datenblock, Prüfsummen, Codierung und 
Decodierung, Hardware-Register, SYNC, 
Interrupts 

- Diskmonitor 

- Fast-Copy: Kgmplette Diskette in ca. 1 
Minute kopieren 

- Crunch-Copy: Durch Packroutinen weniger 
Diskettenwechsel 

- Deep-Copy: Kopiert praktisch jeden 
Kopierschutz, ST- und PC-Disketten 

- Floppyspeeder: Superschnelle 
TrackdIsk-Routinen beschleunigen den 
Diskettenzugriff 


Abraham, Gelfand, Grote 
Das große Amiga-Floppybuch 
557 Seiten, DM 59,- 
ISBN 3-89011-180-7 




Bücher zu Amiga 


Schreiben Sie Ihre Programme in Maschinenesprache - und 
Sie werden sehen, wie schnell ein Amiga sein kann. Das 
nötige Know-how liefert Ihnen dieses Buch: Grundlagen des 
68000, das Amiga-Betriebssystem, Druckeransteuerung, 
Diskettenoperationen, Sprachausgabe, Windows, Screens, 
Register, Pull-Down-Menüs . . . Aber es wird auch gleich 
gezeigt, wie man mit den wichtigsten Assemblern arbeitet. 



Dittrich 

Amiga Maschinensprache 
Hardcover, 288 Seiten, DM 49,- 
ISBN 3’89011-076-2 
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DAS STEHT DRIN: 


Wer den Einstieg in C geschafft hat, wird sich so manches Mal fragen, warum 
das gut durchdachte Programm nicht funktioniert. Hier helfen fundierte Informa¬ 
tionen von Profis weiter: Funktionsweise von Compiler Assembler und Linker 
(am Beispiel von Aztec 3.6 und Lattice 4.0), komfortable Oberflächen für eigene 
Programme mit Intuition und ein großes Projekt professionell programmiert - 
mit diesem Buch bleibt keine Frage offen. 


Aus dem Inhalt: 

• Funktionsweise des Aztec-Compilers (Compiler, Assembler, Linker) 

• Wie funktionieren INCLUDE, DEFINE und CASTS? 

• Debugging und Optimierung des Assembler-Sources 

• Knifflige Programmierprobleme: Sprungtabellen und dynamische Arrays In C 

• Einbinden von Assembler-Source in den C-Source 

• Alles über Intuition-Programmierung (Windows, Screens, Pulldown-Menüs, 
Requester, Gadgets) 

• Programmierung des Console-Device 

• Ein professioneller Editor zeigt alle Probleme bei der Erstellung größerer 
Programme 

• Richtiger Einsatz von MAKE 

• Debugging von C-Programmen mit verschiedenen Hilfsmitteln 

• Ein kompletter Text-Editor als Source in mehreren Entwicklungsstufen 

• Folding-Technik (Der Editor kann Textteile und Funktionen wegfalten, das 
erhöht die Übersichtlichkeit enorm.) 


UND GESCHRIEBEN HABEN DIESES BUCH: 

Bruno Jennrich stellte bereits mit den Büchern „Amiga Intern Band 11“ und „Ami- 
ga 3-D-Grafikprogrammierung“ seine Programmierkenntnisse unter Beweis. 
Wolf-Gideon Bleek hat in dem Buch „Amiga Tips & Tricks“ viele Kniffe zurWork- 
bench und zu Intuition vorgestellt. Peter Schulz hat mit dem PROFI MAT AMIGA 
professionelle Programmierqualitäten bewiesen; mit dem Texteditor In diesem 
Buch hat er endlich „seinen“ Editor geschrieben. 


ISB N 3-89011-191-2 DM +069.00 


DM 69,- 
ÖS 538,- 
sFr 67,- 
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